Cookie Store API とは
Cookie Store API は HTTP Cookie を Service Worker に公開します。
には、document.cookie の非同期の代替手段が用意されています。API を使えば、
次のようなメリットがあります。
- Cookie に非同期的にアクセスして、メインスレッドでジャンクが発生しないようにします。
- Cookie の変更を監視することがあるため、Cookie のポーリングは避けてください。
- Service Worker から Cookie にアクセスする。
現在のステータス
| ステップ | ステータス |
|---|---|
| 1. 説明を作成 | 完了 |
| 2. 仕様の初期ドラフトを作成する | 完了 |
| **3.フィードバックの収集と仕様に沿って反復処理** | **処理中** |
| 4. オリジン トライアル | 一時停止 |
| 5. リリース | 開始していません |
非同期 Cookie ストアの使用方法
オリジン トライアルを有効にする
ローカルで試すには、コマンドラインで API を有効にします。
chrome --enable-blink-features=CookieStore
このフラグをコマンドラインに渡すと、Chrome for Work の API がグローバルに クリックします。
また、#enable-experimental-web-platform-features を有効にすることもできます。
chrome://flags のフラグ。
Cookie は（おそらく）必要ない
新しい API の説明に入る前に、Cookie は今でもウェブの技術であると言えます。 クライアントサイド ストレージ プリミティブであり、依然として API として 最後の手段です。これは偶発的ではない - Cookie はウェブにおける最初のクライアントサイド それ以来、多くのことを学びました。
Cookie の使用を避ける主な理由は次のとおりです。
Cookie は、ストレージ スキーマをバックエンド API に取り込みます。 各 HTTP リクエストには Cookie jar のスナップショットが含まれます。そのため バックエンド エンジニアに現在の Cookie 形式への依存を導入してもらう必要があります。1 回 フロントエンドのストレージスキーマを変更するために バックエンドに対して一致する変更を 返すことです
Cookie には複雑なセキュリティ モデルがあります。 最新のウェブ プラットフォーム機能は、同じオリジン ポリシーに従います。つまり、 各アプリケーションは独自のサンドボックスを取得しており、 ユーザーが実行している可能性のある他のアプリケーションです。 Cookie スコープ セキュリティ上の状況が大幅に複雑になります。 記事のサイズが 2 倍になります
Cookie は高いパフォーマンス コストをもたらします。ブラウザには、このアプリケーションの すべての HTTP リクエストで Cookie が削除されるため、Cookie に対する変更はすべて、 ネットワーク スタック全体に伝播されます。最新のブラウザでは、 Cookie ストアの実装が最適化されますが Cookie は他のストレージ メカニズムと同程度に効率的です。ストレージ メカニズムでは、 ネットワークスタックに送られます
上記のすべての理由から、最新のウェブ アプリケーションでは Cookie と 代わりにセッション ID を IndexedDB 特定の HTTP リクエストのヘッダーまたは本文に識別子を明示的に追加する。 fetch API で取得します。
とはいえ、あなたは良い Cookie を使用する理由
Cookie を読み取ってジャンクを除去する
由緒あるもの
document.cookie
API は、アプリケーションにとってかなり保証されたジャンク発生源です。たとえば
document.cookie ゲッターを使用するたびに、ブラウザは実行を停止する必要がある
リクエストした Cookie 情報が取得されるまで JavaScript を待機します。これには
UI がジャンクの原因となります。
この問題の簡単な解決策は、document.cookie から切り替えることです。
非同期の Cookie Store API にゲッターを送ります。
await cookieStore.get('session_id');
// {
// domain: "example.com",
// expires: 1593745721000,
// name: "session_id",
// path: "/",
// sameSite: "unrestricted",
// secure: true,
// value: "yxlgco2xtqb.ly25tv3tkb8"
// }
document.cookie セッターも同様の方法で置き換えることができます。留意点
変更の適用は、Promise によって返された Promise の後のみに
cookieStore.set が解決します。
await cookieStore.set({name: 'opt_out', value: '1'});
// undefined
観察はするがポーリングはしない
JavaScript から Cookie にアクセスするための一般的なアプリケーションでは、
ユーザーがログアウトし、UI を更新します。これは現在、ポーリングによって行われます。
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 は非同期であるため、サービスで使用できます。
できます。
Cookie の扱いは、ドキュメントのコンテキストや 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 コンポーネント。
特に重要なのは、パフォーマンスの測定方法や 説明で説明されている以外のケースが対象となります。
参考情報
- 公開解説
- の仕様
- バグのトラッキング
- chromestatus.com のエントリ
- WICG の談話スレッド
- Blink コンポーネント:
Blink>Storage>CookiesAPI