このページは Cloud Translation API によって翻訳されました。

HTTP Cookie への非同期アクセス

Victor Costan

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