这是
实验性技术
检查
浏览器兼容性表格
要小心谨慎在生产中使用这之前。
The Storage Access API provides a way for embedded, cross-origin content to gain unrestricted access to storage that it would normally only have access to in a first-party context (we refer to this as an origin’s first-party storage). The API provides methods that allow embedded resources to check whether they currently have access to their first-party storage, and to request access to their first-party storage from the user agent.
Most browsers implement a number of storage access policies that restrict access to cookies and site data for embedded, cross-origin resources. These restrictions range from giving embedded resources under each top-level origin a unique storage space to outright blocking of storage access when resources are loaded in a third-party context.
The semantics around third-party cookie blocking policies in particular differ from browser to browser, but the core functionality is similar: cross-origin resources embedded in a third-party context are not given access to the same cookies and site storage that they would have access to when loaded in a first-party context.
These cookie blocking policies are known to break embedded cross-origin content that requires access to its first-party storage. As an example, federated logins often require access to authentication cookies stored in first-party storage, and will require the user to sign in on each site separately (or completely break) if those cookies are not available. In the case of breakage, site owners have often encouraged users to add their site as an exception or to disable the policy entirely. As a consequence, users who wish to continue to interact with embedded content are forced to greatly relax their blocking policy for resources loaded from all embedded origins and possibly across all websites.
The Storage Access API is intended to solve this problem; embedded cross-origin content can request unrestricted access to its first-party storage on a site-by-site basis via the
Document.requestStorageAccess()
method, and check whether it already has access via the
Document.hasStorageAccess()
方法。
In addition, sandboxed
<iframe>
s cannot be granted storage access by default for security reasons. The API therefore also adds the
allow-storage-access-by-user-activation
sandbox token
. The embedding website needs to add this to allow storage access requests to be successful, along with
allow-scripts
and
allow-same-origin
to allow it to call the API, and execute in an origin that can have cookies:
<iframe sandbox="allow-storage-access-by-user-activation
allow-scripts
allow-same-origin">
...
</iframe>
The API is designed to limit the potential storage exceptions to origins for which the user has shown an intent to interact. This is enforced through the following constraints:
The browser may decide to involve the user in the decision of whether to grant an incoming storage access request. Specifics regarding the lifetime of a storage grant and the circumstances under which the browser may decide to inform the user are currently being worked through and will be announced once ready.
当
requestStorageAccess()
is called by an embedded, cross-origin document, the user agent may choose to involve the user in the decision of whether to grant storage access to the requesting origin. Prompting heuristics currently vary across the two implementers of the Storage Access API — Safari shows prompts for all embedded tracking content that has not previously received storage access, while Firefox only prompts users after a tracking origin has requested storage access on more than a threshold number of sites. See
Document.requestStorageAccess()
了解更多细节。
Although the API surface is the same, websites using the Storage Access API should expect differences in the level and extent of storage access they receive between Firefox and Safari. This is caused by differences in the storage access policies implemented in the two browsers. Design properties unique to Firefox are summarized here:
tracker.example
has already obtained first-party storage access on the top-level origin
foo.example
, and the user visits a page from
foo.example
embedding a page from
tracker.example
again in less than 30 days, the embedded origin will have storage access immediately when loading.
foo.example
embeds more than one
<iframe>
from
tracker.example
, and one of those
<iframe>
s uses the Storage Access API in order to obtain storage access successfully, all other iframes from
tracker.example
on
foo.example
top-level origins will immediately gain storage access as well, without needing to call
requestStorageAccess()
separately.
tracker.example
has previously successfully obtained storage access on top-level origin
foo.example
, all embedded subresources from
tracker.example
on
foo.example
(e.g. scripts, images, stylesheets, etc.) will load with access to their first-party storage, which means they may send Cookie headers and honor incoming
Set-Cookie
头。
requestStorageAccess()
is resolved, the embedded page will gain access to its entire first-party storage, not just cookies. This includes access to APIs such as
Web 存储
,
IndexedDB
,
DOM Cache
, and so on.
Documentation for Firefox's new storage access policy for blocking tracking cookies includes a detailed description of the scope of storage access grants.
The storage API methods are implemented on the
Document
接口：
Document.hasStorageAccess()
Promise
that resolves with a boolean value indicating whether the document has access to its first-party storage.
Document.requestStorageAccess()
Promise
that resolves if the access to first-party storage was granted, and rejects if access was denied.
注意 : User interaction propagates to the Promise returned by both of these methods, allowing the callers to take actions that require user interaction without requiring a second click from the user. For example, a caller could open a pop-up window from the resolved Promise without triggering Firefox’s pop-up blocker.
<iframe>
元素的
sandbox
attribute has a new token,
allow-storage-access-by-user-activation
, which permits sandboxed
<iframe>
s to use the Storage Access API to request storage access.
The API is currently only at the proposal stage — the standardization process has yet to begin. You can currently find specification details of the API at Apple's Introducing Storage Access API blog post, and WHATWG HTML issue 3338 — Proposal: Storage Access API .
| 桌面 | 移动 | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
hasStorageAccess
非标
|
Chrome No | Edge No | Firefox 65 | IE No | Opera No | Safari 11.1 | WebView Android No | Chrome Android No | Firefox Android 65 | Opera Android No | Safari iOS 11.3 | Samsung Internet Android No |
完整支持
不支持
实验。期望将来行为有所改变。
非标。预期跨浏览器支持较差。
用户必须明确启用此特征。
| 桌面 | 移动 | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
requestStorageAccess
非标
|
Chrome No | Edge No | Firefox 65 | IE No | Opera No | Safari 11.1 | WebView Android No | Chrome Android No | Firefox Android 65 | Opera Android No | Safari iOS 11.3 | Samsung Internet Android No |
完整支持
不支持
实验。期望将来行为有所改变。
非标。预期跨浏览器支持较差。
用户必须明确启用此特征。