HTTP Cookie 非同步存取

什麼是 Cookie Store API？

Cookie Store API 會向 Service Worker 公開 HTTP Cookie， 提供了 document.cookie 的非同步替代方案。這個 API 讓 更容易：

• 以非同步方式存取 Cookie，避免主執行緒上卡頓。
• 系統會觀測 Cookie 的變更，因此請避免輪詢 Cookie。
• 存取服務工作人員的 Cookie。

閱讀說明

目前狀態

如何使用非同步 Cookie 儲存庫？

啟用來源試用

如要在本機試用，可以透過指令列啟用 API：

chrome --enable-blink-features=CookieStore

在指令列中傳遞此標記，即可在全球的 Chrome 中啟用 API，方便 目前的工作階段。

或者，您也可以啟用 #enable-experimental-web-platform-features 標記在 chrome://flags 中。

您可能不需要 Cookie

開始使用新的 API 前，我想先表明 Cookie 仍是網頁版 平台最差的用戶端儲存空間基本儲存，因此仍應做為 不得已。這不是意外，Cookie 是網路的第一個用戶端 我們從那時就學到很多

避免使用 Cookie 的主要原因包括：

• Cookie 會將儲存空間結構定義帶入後端 API。 每個 HTTP 要求都會有 Cookie jar 的快照。這樣一來 導入後端工程師，導入對現行 Cookie 格式的依附關係。一次 因此，後端必須部署 Google Cloud 資源，才能變更儲存空間結構定義 與後端相符的變更

• Cookie 有複雜的安全性模型。 現代網路平台功能遵循相同的來源政策，意味著 每個應用程式都有各自的沙箱，而且完全獨立於 使用者可能正在執行的其他應用程式。 Cookie 範圍 只是想建構更複雜的安全機制 因為這麼做可以加倍顯示這篇文章

• Cookie 的效能成本高。瀏覽器需包含 設為每次 HTTP 請求中的 Cookie，因此每次對 Cookie 進行的變更都必須 並傳播至整個儲存空間和網路堆疊新式瀏覽器具有高度 最佳化 Cookie 儲存庫導入作業，但我們永遠無法 Cookie 與其他儲存機制一樣有效率，不必透過 網路堆疊

基於上述所有原因，新式網頁應用程式應避免使用 Cookie 和 而是會將工作階段 ID IndexedDB 和 將識別碼明確加入特定 HTTP 要求的標頭或內文 透過 fetch API

即便如此，您還是需要閱讀這篇文章， 使用 Cookie 的理由...

讀取餅乾並消除資源浪費

備受尊敬的 document.cookie API 對應用程式來說是合理的卡頓來源。例如： 當您使用 document.cookie getter 時，瀏覽器必須停止執行 直到瀏覽器取得您要求的 Cookie 資訊為止。這可能需要 程序躍點或讀取磁碟，並導致 UI 發生卡頓。

這個問題的直接修正方式是從 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，某個熱門應用程式 使用者登出並更新 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);
  }
});

歡迎服務工作人員

有同步設計，因此尚未對 document.cookie API 進行 適用對象 服務 Worker。 Cookie Store API 為非同步性質，因此可於服務中使用 工作站

在文件內容與 Cookie 中，與 Cookie 的互動方式相同 Service Worker。

// Works in documents and service workers.
async function logOut() {
  await cookieStore.delete('session_id');
}

不過，在服務工作處理程序中，觀察 Cookie 的變更會有些許不同。醒來 因此需要明確說明 並記錄工作者感興趣的 Cookie。

在以下範例中，應用程式使用 IndexedDB 快取使用者資料 它會監控工作階段 Cookie 的變更，在工作階段 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 形狀的意見回饋 規格存放區 並向 SDK 回報實作錯誤 Blink>Storage>CookiesAPI敬上 閃爍元件。

我們尤其想學習成效評估和使用方式 。說明中未明確標示的情況。

其他資源

• 公開說明
• 規格
• 追蹤錯誤
• chromestatus.com 項目
• WICG 討論討論串
• 閃爍元件：Blink>Storage>CookiesAPI