快速了解 Storage Access API
相信坚持的力量！今天是坚持日更的第119天，记得点击关注、点赞、在看支持我呦
Chrome 浏览器计划从 2024 年第一季度开始禁用 1% 用户的第三方 Cookie，以方便测试，然后在 2024 年第三季度逐步覆盖到 100% 用户。Chrome 推出了一系列API，为诸如身份验证、广告和欺诈检测等用例提供了以隐私为重点的替代方案。
本文主要介绍 Storage Access API，网站可以使用它来请求跨站点的 Cookie 访问权限。当网站在同一组中时，浏览器会自动授予访问权限，并且跨站点的 Cookie将可用。这意味着相关网站的组仍然可以在有限的上下文中使用跨站点的 Cookie，但不会冒着以允许跨站点追踪的方式在不相关的站点之间共享第三方cookie的风险。
什么是 Storage Access API？
Storage Access API 是一种 JavaScript API，为跨域 iframe 提供了两项新功能 —— document.hasStorageAccess() 和document.requestStorageAccess()。它还为嵌入的顶级 frame 提供了一个新的 iframe sandbox token —— “allow-storage-access-by-user-activation”。
在这种情况下，Storage Access（存储可访问）意味着 iframe 可以访问宿主站点的 cookie，即它可以像宿主站点一样访问当前网站的 cookie。注意，storage access 不会以任何方式放宽同源策略。具体来说，这并不是指第三方 iframe 能访问宿主站点的 cookie 和存储，反之亦然。
浏览器支持情况
Storage Access API 适用于所有主流浏览器，但各个浏览器之间存在细微的实现差异。
应用场景
某些第三方嵌入代码需要访问跨网站 Cookie 才能为用户提供更好的体验，而这在第三方 Cookie 被弃用后将无法使用。用例包括：
需要登录会话详细信息的嵌入式评论 widget。 需要登录会话详细信息的社交媒体“赞”按钮。 需要登录会话详细信息的嵌入式文档。 为嵌入视频提供的优质体验（例如，不向已登录的用户展示广告，或者了解用户对字幕的偏好或限制某些视频类型）。 嵌入式支付系统。 其中许多用例都涉及在嵌入式 iframe 中持久保留登录访问权限。
何时使用
Storage Access API 是使用第三方 Cookie 的替代方案之一，因此，与其他 API 相比，了解何时使用此 API 非常重要。它适用于同时满足以下两个条件的用例：
用户会与嵌入的内容互动，也就是说，嵌入的内容不是被动 iframe 或隐藏 iframe。 用户已在顶级上下文中访问了嵌入的来源，即该来源未嵌入到其他网站中。
有适用于各种用例的替代 API：
借助具有独立分区状态的 Cookie (CHIPS)，开发者可以选择启用 Cookie“分区”存储，并为每个顶级网站分别设置单独的 Cookie jar。例如，第三方网络聊天微件可能需要设置 Cookie 才能保存会话信息。会话信息是按网站保存的，因此您无需在嵌入了微件的其他网站上访问由此微件设置的 Cookie。如果嵌入式第三方 widget 依赖于跨不同源共享相同的信息（例如，登录会话详细信息或偏好设置），则 Storage Access API 非常有用。 Related Websites Sets (RWS) 可让组织声明网站之间的关系，以便浏览器允许出于特定目的对第三方 Cookie 进行有限的访问。网站仍需要使用 Storage Access API 请求访问权限，但对于集合中的网站，无需用户提示即可授予访问权限。 联合凭据管理 (FedCM) 是一种联合身份服务可保护隐私的方法。Storage Access API 用于处理登录后访问 Cookie。对于某些用例，FedCM 为 Storage Access API 提供了替代解决方案，由于它具有更面向登录的浏览器提示，因此可能是首选解决方案。但是，采用 FedCM 通常需要对代码进行额外的更改，例如支持其 HTTP 端点。 此外，还存在防欺诈 API、广告相关 API 和衡量 API，Storage Access API 无意解决此类问题。
快速上手
Storage Access API 有两种基于 promise 的方法：
Document.hasStorageAccess()Document.requestStorageAccess()
它还与 Permissions API 集成。这样，您就可以在第三方上下文中检查存储访问权限的状态，该状态会指示是否会自动授予对 document.requestStorageAccess() 的调用：
navigator.permissions.query({name: "storage-access"});
hasStorageAccess()
首次加载网站时，网站可以使用 hasStorageAccess() 方法检查是否已授予对第三方 Cookie 的访问权限。
// Set a hasAccess boolean variable which defaults to false.
let hasAccess = false;
async function handleCookieAccessInit() {
if (typeof document.hasStorageAccess !== 'function') {
// Storage Access API is not supported so best we can do is
// hope it's an older browser that doesn't block 3P cookies.
hasAccess = true;
} else {
// Check whether access has been granted via the Storage Access API.
// Note on page load this will always be false initially so we could be
// skipped in this example, but including for completeness for when this
// is not so obvious.
hasAccess = await document.hasStorageAccess();
if (!hasAccess) {
// Handle the lack of access (covered later)
}
}
if (hasAccess) {
// Use the cookies.
}
}
handleCookieAccessInit();
只有在 iframe 文档调用 requestStorageAccess() 后，系统才会向其授予存储空间访问权限，因此 hasStorageAccess() 最初将始终返回 false，但同一 iframe 中的另一个同源文档已被授予访问权限时除外。在 iframe 内的同源导航中，授权将保留，特别是在对要求在 HTML 文档初始请求中存在 Cookie 的网页授予访问权限后，允许重新加载。
requestStorageAccess()
如果 iframe 没有访问权限，可能需要使用 requestStorageAccess() 方法请求访问权限：
if (!hasAccess) {
try {
await document.requestStorageAccess();
} catch (err) {
// Access was not granted and it may be gated behind an interaction
return;
}
}
首次请求此权限时，用户可能需要通过浏览器提示批准此访问权限，之后 promise 将进行解析，或拒绝此请求，从而引发异常（如果使用了 await）。
为防止滥用行为，此浏览器提示仅在用户互动后显示。因此，最初需要通过用户激活的事件处理脚本调用 requestStorageAccess()，而不是在 iframe 加载时立即调用：
async function doClick() {
// Only do this extra check if access hasn't already been given
// based on the hasAccess variable.
if (!hasAccess) {
try {
await document.requestStorageAccess();
hasAccess = true; // Can assume this was true if above did not reject.
} catch (err) {
// Access was not granted.
return;
}
}
if (hasAccess) {
// Use the cookies
}
}
document.querySelector('#my-button').addEventListener('click', doClick);
Cookie 要求
要在 Chrome 中通过 Storage Access API 进行访问，必须使用以下两个属性设置跨网站 Cookie：
SameSite=None - 必须提供此值，才能将 Cookie 标记为跨网站 Secure - 用于确保只能访问由 HTTPS 网站设置的 Cookie。
在 Firefox 和 Safari 中，Cookie 默认为 SameSite=None，并不将 SSA 限制为 Secure Cookie，因此这些属性不是必需的。建议您明确说明 SameSite 属性并始终使用 Secure Cookie。
大家都在看