Note: This feature is available in Web Workers.
The Permissions API provides a consistent programmatic way to query the status of API permissions attributed to the current context, such as a web page or worker. For example, it can be used to determine if permission to access a particular feature or API has been granted, denied, or requires specific user permission.
Concepts and usageHistorically different APIs handle their own permissions inconsistently â for example the Notifications API provided its own methods for requesting permissions and checking permission status, whereas the Geolocation API did not. The Permissions API provides the tools to allow developers to implement a consistent user experience for working with permissions.
The permissions from this API effectively aggregate all security restrictions for the context, including any requirement for an API to be used in a secure context, Permissions-Policy restrictions applied to the document, requirements for user interaction, and user prompts. So, for example, if an API is restricted by permissions policy, the returned permission would be denied
and the user would not be prompted for access.
The permissions
property has been made available on the Navigator
object, both in the standard browsing context and the worker context (WorkerNavigator
â so permission checks are available inside workers), and returns a Permissions
object that provides access to the Permissions API functionality.
Once you have this object you can then use the Permissions.query()
method to return a promise that resolves with the PermissionStatus
for a specific API.
If the permission status is prompt
, the user must acknowledge a prompt to grant access to the feature.
The mechanism that triggers this prompt will depend on the specific API â it is not defined as part of the Permissions API. Generally the trigger is code calling a method to access or open the feature, or that registers for notifications from the feature that will subsequently access it.
Note that not all features require a prompt. Permission might be granted by a Permission Policy
, implicitly by transient activation, or via some other mechanism.
Permission revocation is not managed by the API. More specifically, a Permissions.revoke()
method was proposed, but has since been removed from those browsers where it was implemented.
Users can manually remove permission for particular sites using browser settings:
Not all APIs' permission statuses can be queried using the Permissions API. A non-exhaustive list of permission-aware APIs includes:
background-sync
(should always be granted)clipboard-read
, clipboard-write
compute-pressure
geolocation
local-fonts
microphone
, camera
notifications
payment-handler
push
screen-wake-lock
accelerometer
, gyroscope
, magnetometer
, ambient-light-sensor
storage-access
, top-level-storage-access
persistent-storage
bluetooth
midi
window-management
Permissions
Provides the core Permission API functionality, such as methods for querying and revoking permissions.
PermissionStatus
Provides access to the current status of a permission, and an event handler to respond to changes in permission status.
Navigator.permissions
and WorkerNavigator.permissions
Read only
Provides access to the Permissions
object from the main context and worker context respectively.
We have created an example called Location Finder. You can run the example live, view the source code on GitHub, or read more about how it works in our article Using the Permissions API.
The Permissions.query()
example also so shows code that tests most permissions on the current browser and logs the result.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.3