WebExtensions/Implementing APIs out-of-process: Difference between revisions

restrictions -> allowedContexts - bugzil.la/1302898
(Fix some typos and formatting)
(restrictions -> allowedContexts - bugzil.la/1302898)
Line 131: Line 131:
control in addition to permissions, <code>shouldInject</code> can be used.
control in addition to permissions, <code>shouldInject</code> can be used.
<code>shouldInject</code> receives parameters to identify which function is being called, and an optional
<code>shouldInject</code> receives parameters to identify which function is being called, and an optional
array of "restrictions". These "restrictions" can be declared in a JSON schema to annotate certain
array of "allowedContexts". These "allowedContexts" can be declared in a JSON schema to annotate certain
APIs and enforce access control. The next example shows how content scripts are withheld of all APIs
APIs and enforce access control. The next example shows how content scripts are withheld of all APIs
unless enabled explicitly by adding the "content" restriction to the JSON schema.
unless enabled explicitly by adding "content" to "allowedContexts" in the JSON schema.


   shouldInject(namespace, name, restrictions) {
   shouldInject(namespace, name, allowedContexts) {
     // Do not generate content script APIs, unless explicitly allowed.
     // Do not generate content script APIs, unless explicitly allowed.
     if (this.context.envType === "content_child" &&
     if (this.context.envType === "content_child" &&
         (!restrictions || !restrictions.includes("content"))) {
         !allowedContexts.includes("content")) {
       return false;
       return false;
     }
     }
Line 144: Line 144:
   }
   }


With "restrictions", schema APIs are completely disabled unless the schema specifies a restriction.
With the above check, schema APIs are completely disabled unless the JSON schema specifies the context in "allowedContexts".
With "permissions", schema APIs are enabled, unless the schema specifies a permission that the
With "permissions", schema APIs are enabled, unless the schema specifies a permission that the
extension lacks.
extension lacks.


Any API node can be annotated with "restrictions". To cater for the use case where a full namespace
Any API node can be annotated with "allowedContexts". To cater for the use case where a full namespace
should be made available, the "defaultRestrictions" key can be used. Note that when a restriction is
should be made available, the "defaultContexts" key can be used. Note that when "allowedContexts" is
used to opt into an API (like the above example with "content"), then the namespace declaration in
used to opt into an API (like the above example with "content"), then the namespace declaration in
the JSON schema must also be annotated with the "restrictions" key.
the JSON schema must also be annotated with the "allowedContexts" key.


Here are some examples of code that migrated from being untyped to using schemas to enforce types:
Here are some examples of code that migrated from being untyped to using schemas to enforce types (note that "allowedContexts" / "defaultContexts" was initially called "restrictions" / "defaultRestrictions", but that changed in [https://bugzil.la/1302898 bug 1302898]):


* i18n API - https://hg.mozilla.org/mozilla-central/rev/e4ce08beaf74
* i18n API - https://hg.mozilla.org/mozilla-central/rev/e4ce08beaf74
44

edits