[TOC]
The
PermissionController
is the entry point for clients of the permissions infrastructure from both the
//content
and the embedder (e.g. //chrome
) layers.
PermissionController
provides access to the permissions API and can be reached as
content::BrowserContext::GetPermissionController()
or
Profile::GetPermissionController()
.
PermissionController has the following API:
blink::mojom::PermissionStatus PermissionController::GetPermissionStatusForWorker
blink::mojom::PermissionStatus PermissionController::GetPermissionStatusForCurrentDocument
blink::mojom::PermissionStatus PermissionController::GetPermissionStatusForOriginWithoutContext
Use this API only in special cases when there is no active document or
worker. E.g., PermissionType::PAYMENT_HANDLER
permission verification of
payment providers in a PWA’s manifest.PermissionController::RequestPermissionFromCurrentDocument
PermissionController::RequestPermissionsFromCurrentDocument
The PermissionControllerImpl
is the implementation of the
PermissionController.
PermissionControllerImpl
is meant to be used only internally in //content
and is not available for
external clients.
PermissionControllerImpl provides various functionality such as:
The PermissionManager is an implementation of PermissionControllerDelegate. PermissionManager is a KeyedService which means it is attached to a BrowserContext. It allows to get permission status for ContentSettingsType. That API should be used only to display permission status in UI like PageInfo and SiteSettings.
Internally,
PermissionManager
holds a list of PermissionsContexts, one per
ContentSettingType.
PermissionContextBase
is the base class for these contexts, and for every
ContentSettingsType
there is a specific ...PermissionsContext
subclass.
EXAMPLE: NotificationPermissionContext handles the «NOTIFICATIONS« content setting.
In order to query, set, and reset the state of a permission, the HostContentSettingsMap KeyedService is used, which internally handles the more complicated things related to Content Settings.
In order to present the user with a permission prompt when a permission is requested, PermissionRequestManager is used.
In order to determine whether a permission is granted, blocked, needs a user decision, etc, the appropriate content setting is checked. Content settings are saved and retrieved using a key consisting of a 3-tuple of values:
A
ContentSettingsPattern
is basically a URL where every part (scheme, host port, path) is allowed to be
either Wildcard
or a specified value. Any other form or regex is not
supported.
A key that has Wildcard
for both the primary and secondary patterns represents
the «Default» value for a specific
ContentSettingsType.
This is the least specific content setting that will match anything and serves
as a backup for when no more-specific setting has been set.
When setting or retrieving a content setting, the HostContentSettingsMap uses a list of registered providers. This enum is sorted from highest priority to lowest. If a provider is able to handle a specific operation it will do so and the following providers are ignored, otherwise the next provider is queried and so on.
The underlying storage mechanism is provider-dependent.
The
PermissionRequestManager
facilitates making permission requests via AddRequest()
. Only one request
prompt is allowed to be in progress at a time, the manager holds a deque of
pending requests for all requests that are kept waiting until the current prompt
is resolved.
The PermissionRequestManager is attached and scoped to the lifetime of a WebContents. When the WebContents object is destroyed all current and queued requests are finalized as «IGNORED».
It is possible to have more than one request be tied in to the same prompt. This only happens when the requests are allowed to be grouped together and they all requested one after another. Currently this is only the case for the Camera and Microphone permissions which can be grouped into one Camera+Microphone prompt.
--deny-permission-prompts
command line switch will cause all
permissions to be automatically denied.If the request has not been automatically resolved, it is added to deque of
queued_requests_
from which it will be picked up as appropriate.
When a trigger causes the DequeueRequestIfNeeded
function to be called it will
check if the necessary conditions are met to show a new permission prompt and it
will trigger showing the prompt. The conditions are:
DequeueRequestIfNeeded
is triggered when:
When the prompt needs to be shown to the user, a platform specific subclass of PermissionPrompt is created which handles the creation and lifetime of the UI element and will report user actions back to the PermissionRequestManager.
The PermissionPrompt is responsible for deciding the exact UI surface and text to present to the user based on information about the request.
For specific permission prompt requests a decision could be made to enforce a quiet UI version of the permission prompt. Currently this only applies to NOTIFICATIONS permission requests.
A quiet UI prompt can be triggered if any of these conditions are met:
The AdaptiveQuietNotificationPermissionUiEnabler is responsible for recording the permission prompts outcomes and, if needed, enabling the quiet UI in settings. The ContextualNotificationPermissionUiSelector checks if the quiet UI is enabled in settings (among other things) when choosing the appropriate UI flavor.
A quiet UI prompt will use a right-side omnibox indicator on desktop or a mini-infobar on Android.
Requesting and verification of permissions does not feature unified behavior in different environments. In other words, based on the preconditions, a permission request could be shown or automatically declined. To make sure that all cases work as intended, we introduced PermissionsSecurityModelInteractiveUITest.
If you’re adding a new environment that requires non-default behavior for permissions, then you need to add a test in PermissionsSecurityModelInteractiveUITest.
Steps to follow:
VerifyPermissionForXYZ
, where XYZ
is the name of your
environment. You can use the already defined VerifyPermission
method if you
expect to have default behavior for permissions. In VerifyPermissionForXYZ
define a new behavior you expect to have.VerifyPermissionForXYZ
from your newly created test fixture.EXAMPLE: PermissionRequestWithPortalTest enables the Portals. The [PortalActivation] test verifies that permissions are disabled in Portals. VerifyPermissionsDeniedForPortal incapsulates all logic needed for a particular permission verification.