W przeciwieństwie do obszarów przechowywania local
i sync
, obszar managed
wymaga, aby jego struktura
są zadeklarowane jako Schemat JSON i są ściśle weryfikowane przez Chrome. Ten schemat musi być przechowywany w
wskazywany przez właściwość "managed_schema"
klucza manifestu "storage"
i deklaruje
zasad firmowych obsługiwanych przez to rozszerzenie.
Zasady są podobne do opcji, ale konfigurowane przez administratora systemu zamiast przez użytkownika umożliwiając wstępne skonfigurowanie rozszerzenia dla wszystkich użytkowników w organizacji. Zobacz, jak obsługuje się Chrome zasad.
Po zadeklarowaniu zasad można je odczytywać z interfejsu API storage.managed. Zależy to tylko , aby wymuszać stosowanie zasad skonfigurowanych przez administratora.
Przykładowy plik manifest.json
Właściwość storage.managed_schema
wskazuje plik w rozszerzeniu, który zawiera zasadę.
schemat.
{
"name": "My enterprise extension",
"storage": {
"managed_schema": "schema.json"
},
...
}
Następnie Chrome wczyta te zasady z systemu operacyjnego i Google Apps na zalogowanych użytkowników. zdarzenie storage.onChanged jest wywoływane po każdym wykryciu zmiany zasady. także wtedy, gdy przeglądarka nie była uruchomiona, jeśli rozszerzenie korzysta ze stron zdarzeń. Możesz zweryfikować zasady wczytane przez Chrome na stronie chrome://policy.
Format schematu
Format JSON Schema ma dodatkowe wymagania dotyczące Chrome:
- Schemat najwyższego poziomu musi mieć typ
object
. - Element
object
najwyższego poziomu nie może zawierać elementuadditionalProperties
. Zadeklarowaneproperties
to zasad dotyczących tego rozszerzenia. - Każdy schemat musi mieć wartość
$ref
lub dokładnie 1type
.
Jeśli schemat jest nieprawidłowy, Chrome nie załaduje rozszerzenia i poda przyczynę, dla której
nie udało się zweryfikować schematu. Jeśli wartość zasady nie jest zgodna ze schematem, nie zostanie
opublikowane przez interfejs API storage.managed
.
Przykładowy schemat
{
"type": "object",
// "properties" maps an optional key of this object to its schema. At the
// top-level object, these keys are the policy names supported.
"properties": {
// The policy name "AutoSave" is mapped to its schema, which in this case
// declares it as a simple boolean value.
// "title" and "description" are optional and are used to show a
// user-friendly name and documentation to the administrator.
"AutoSave": {
"title": "Automatically save changes.",
"description": "If set to true then changes will be automatically saved.",
"type": "boolean"
},
// Other simple types supported include "integer", "string" and "number".
"PollRefreshRate": {
"type": "integer"
},
"DefaultServiceUrl": {
"type": "string"
},
// "array" is a list of items that conform to another schema, described
// in "items". An example to this schema is [ "one", "two" ].
"ServiceUrls": {
"type": "array",
"items": {
"type": "string"
}
},
// A more complex example that describes a list of bookmarks. Each bookmark
// has a "title", and can have a "url" or a list of "children" bookmarks.
// The "id" attribute is used to name a schema, and other schemas can reuse
// it using the "$ref" attribute.
"Bookmarks": {
"type": "array",
"id": "ListOfBookmarks",
"items": {
"type": "object",
"properties": {
"title": { "type": "string" },
"url": { "type": "string" },
"children": { "$ref": "ListOfBookmarks" }
}
}
},
// An "object" can have known properties listed as "properties", and can
// optionally have "additionalProperties" indicating a schema to apply to
// keys that aren't found in "properties".
// This example policy could map a URL to its settings. An example value:
// {
// "youtube.com": {
// "blocklisted": true
// },
// "google.com": {
// "bypass_proxy": true
// }
// }
"SettingsForUrls": {
"type": "object",
"additionalProperties": {
"type": "object",
"properties": {
"blocklisted": { "type": "boolean" },
"bypass_proxy": { "type": "boolean" }
}
}
}
}
}