什么是 Cookie Store API?
Cookie Store API 会向 Service Worker 公开 HTTP Cookie,
提供 document.cookie
的异步替代方案。通过 API
更轻松地:
- 通过异步访问 Cookie,避免主线程出现卡顿。
- 避免轮询 Cookie,因为可以观察到对 Cookie 的更改。
- 从 Service Worker 访问 Cookie。
当前状态
步骤 | 状态 |
---|---|
1. 创建铺垫消息 | 完成 |
2. 创建规范的初始草稿 | 完成 |
**3.收集反馈和根据规范进行迭代** | **进行中** |
4. 源试用 | 已暂停 |
5. 发布 | 尚未开始 |
如何使用异步 Cookie 存储区?
启用源试用
如需在本地试用,可以在命令行中启用该 API:
chrome --enable-blink-features=CookieStore
通过命令行传递此标志,会在 Chrome 中为 当前会话
或者,您也可以启用#enable-experimental-web-platform-features
标志(在 chrome://flags
中)。
您(可能)不需要 Cookie
在深入了解这个新 API 之前,我想先说明一下,Cookie 仍然是网络 平台最差的客户端存储原语,仍应用作 。这不是意外,Cookie 是网络的第一个客户端 此后,我们学习了很多知识。
避免使用 Cookie 的主要原因如下:
Cookie 可将存储架构导入后端 API。 每个 HTTP 请求都带有 Cookie jar 的快照。这样,你可以轻松 引入对当前 Cookie 格式的依赖性。一次 如果发生这种情况,您的前端必须部署 对后端进行匹配的更改
Cookie 具有复杂的安全模型。 现代网络平台功能遵循同源政策,这意味着 每个应用都有自己的沙盒,并且完全独立于 用户可能正在运行的其他应用 Cookie 范围 却只是试图解决一个要复杂得多的安全故事 将本文的内容加倍。
Cookie 的性能成本很高。浏览器需要包含 因此,对 Cookie 的每次更改都必须 会传播到存储空间和网络堆栈现代浏览器 只不过我们永远无法 Cookie 和其他存储机制一样高效, 加入网络堆栈
出于上述所有原因,现代网络应用应避免使用 Cookie 和 而是将会话标识符 IndexedDB 和 将标识符明确添加到特定 HTTP 请求的标头或正文中, 通过 fetch API 提取。
不过,您仍在阅读这篇文章,因为您已经获得了 使用 Cookie 的理由...
读取 Cookie 并消除卡顿
庄严肃穆
document.cookie
API 可以保证会造成应用卡顿。例如:
每当您使用 document.cookie
getter 时,浏览器都必须停止执行
JavaScript,直到其中包含您请求的 Cookie 信息。这可能需要
进程跳动或磁盘读取,这将导致界面卡顿。
若要解决此问题,一种简单的方法是从 document.cookie
异步 Cookie Store API 的 getter。
await cookieStore.get('session_id');
// {
// domain: "example.com",
// expires: 1593745721000,
// name: "session_id",
// path: "/",
// sameSite: "unrestricted",
// secure: true,
// value: "yxlgco2xtqb.ly25tv3tkb8"
// }
可以采用类似的方式替换 document.cookie
setter。注意事项
更改仅保证在调用
cookieStore.set
解析。
await cookieStore.set({name: 'opt_out', value: '1'});
// undefined
观察,不投票
一种通过 JavaScript 访问 Cookie 的热门应用可检测何时
用户退出登录并更新界面。这目前通过轮询
document.cookie
,会导致卡顿并对电池产生负面影响
生活。
Cookie Store API 提供了一种观察 Cookie 的替代方法 无需轮询。
cookieStore.addEventListener('change', event => {
for (const cookie of event.changed) {
if (cookie.name === 'session_id') sessionCookieChanged(cookie.value);
}
for (const cookie of event.deleted) {
if (cookie.name === 'session_id') sessionCookieChanged(null);
}
});
欢迎 Service Worker
由于采用同步设计,document.cookie
API 尚未
提供给
Service Worker。
Cookie Store API 是异步的,因此允许用于服务
worker。
在文档上下文和 Google Analytics 中, Service Worker。
// Works in documents and service workers.
async function logOut() {
await cookieStore.delete('session_id');
}
不过,在 Service Worker 中观察 Cookie 变化的做法略有不同。醒来 运行 Service Worker 的成本可能相当高, 工作器感兴趣的 Cookie 变化。
在以下示例中,使用 IndexedDB 缓存用户数据的应用 监控会话 Cookie 的变化,并在 用户退出。
// Specify the cookie changes we're interested in during the install event.
self.addEventListener('install', event => {
event.waitUntil(cookieStore.subscribeToChanges([{name: 'session_id'}]));
});
// Delete cached data when the user logs out.
self.addEventListener('cookiechange', event => {
for (const cookie of event.deleted) {
if (cookie.name === 'session_id') {
indexedDB.deleteDatabase('user_cache');
break;
}
}
});
最佳做法
即将推出。
反馈
如果您试用此 API,请告诉我们您的想法!请引导
有关 API 形状的反馈,
规范存储库中
并向
Blink>Storage>CookiesAPI
Blink 组件。
我们特别想知道性能测量和使用 除了说明部分中列出的情况之外,您还需要为 Google 地图和 Google 地图
其他资源
- 公开铺垫消息
- 规格
- 跟踪错误
- chromestatus.com 条目
- WICG 话术会话
- Blink 组件:
Blink>Storage>CookiesAPI