דף זה תורגם על ידי Cloud Translation API.

גישה אסינכרונית לקובצי cookie של HTTP

Victor Costan

מה זה Cookie Store API?

Cookie Store API חושף קובצי cookie של HTTP ל-service worker וגם מציע חלופה אסינכרונית ל-document.cookie. ה-API הופך את קל יותר:

להימנע מ-jank ברשת ה-thread הראשי על ידי גישה לקובצי cookie באופן אסינכרוני.
לא מומלץ לבצע דגימה לקובצי cookie, מכיוון ששינויים בקובצי cookie עשויים להיות גלויים.
גישה לקובצי cookie מ-Service Workers.

לקריאת הסבר

הסטטוס הנוכחי

שלב	סטטוס
1. יצירת הסבר	הושלם
2. יצירת טיוטה ראשונית של מפרט	הושלם
3. איסוף משוב איטרציה במפרט	בתהליך
4. גרסת מקור לניסיון	בהשהיה
5. הפעלה	לא הופעל

איך משתמשים במאגר קובצי ה-cookie האסינכרוני?

הפעלה של גרסת המקור לניסיון

כדי לנסות אותו באופן מקומי, אפשר להפעיל את ה-API בשורת הפקודה:

chrome --enable-blink-features=CookieStore

העברת הדגל הזה בשורת הפקודה מפעילה את ה-API באופן גלובלי ב-Chrome עבור בסשן הנוכחי.

לחלופין, אפשר להפעיל את #enable-experimental-web-platform-features ב-chrome://flags.

(סביר להניח) שאין לך צורך בקובצי Cookie

לפני שממשיכים אל ממשק ה-API החדש, אשמח להצהיר שקובצי cookie הם עדיין דפי אינטרנט את רכיב האחסון הגרוע ביותר בצד הלקוח, ועדיין צריך להשתמש בו מוצא אחרון. זו לא תאונה – קובצי cookie היו בצד הלקוח הראשון באינטרנט מנגנון אחסון, ומאז למדנו הרבה.

הסיבות העיקריות להימנע מקובצי cookie הן:

קובצי Cookie מעבירים את סכימת האחסון ל-API של הקצה העורפי. כל בקשת HTTP נושאת תמונת מצב של מאגר קובצי ה-Cookie. ככה קל מהנדסי קצה עורפי להציג יחסי תלות בפורמט הנוכחי של קובצי cookie. פעם אחת זה קורה, ממשק הקצה לא יכול לשנות את סכימת האחסון שלו בלי לפרוס שינוי תואם בקצה העורפי.
לקובצי cookie יש מודל אבטחה מורכב. לתכונות מודרניות של פלטפורמת אינטרנט יש אותה מדיניות מקור, כלומר לכל אפליקציה יש ארגז חול משלו, והוא לא תלוי בכלל אפליקציות אחרות שהמשתמש עשוי להפעיל. היקפים של קובצי Cookie סיפור אבטחה מורכב יותר, ורק ניסיון כך שיכפלו את הגודל של המאמר הזה.
לקובצי cookie יש עלויות של ביצועים גבוהים. הדפדפנים צריכים לכלול תמונת מצב של קובצי ה-Cookie בכל בקשת HTTP, כך שכל שינוי בקובצי Cookie חייב להיות מופץ ברחבי ערימות האחסון והרשת. לדפדפנים מודרניים יש מותאמות להטמעה של מאגרי קובצי Cookie, אבל אף פעם לא נוכל לבצע קובצי Cookie יעילים כמו מנגנוני אחסון אחרים, שלא צריכים לסטאק הרשת.

מכל הסיבות שצוינו למעלה, אפליקציות אינטרנט מודרניות צריכות להימנע מקובצי Cookie במקום זאת, לשמור מזהה סשן IndexedDB וגם להוסיף את המזהה באופן מפורש לכותרת או לגוף של בקשות HTTP ספציפיות, באמצעות ה-API ל-fetch.

עם זאת, אתה עדיין קורא את המאמר הזה כי יש לך סיבה להשתמש בקובצי Cookie...

קריאת קובץ cookie והסרת jank

הצוות המוערך document.cookie ה-API הוא מקור מובטח למדי של ממשק המשתמש (jank) לאפליקציה שלכם. לדוגמה, בכל שימוש ב-getter של document.cookie, הדפדפן צריך להפסיק לפעול JavaScript עד שהוא יכיל את פרטי קובץ ה-cookie שביקשת. הפעולה עשויה להימשך צעד עיבוד או קריאת דיסק, ויגרמו לממשק המשתמש שלכם לרוץ.

פתרון פשוט לבעיה הזו הוא מעבר מ-document.cookie getter ל-Cookie Store Store האסינכרוני.

await cookieStore.get('session_id');

// {
//   domain: "example.com",
//   expires: 1593745721000,
//   name: "session_id",
//   path: "/",
//   sameSite: "unrestricted",
//   secure: true,
//   value: "yxlgco2xtqb.ly25tv3tkb8"
// }

אפשר להחליף את המגדיר document.cookie באופן דומה. חשוב לזכור מובטח שהשינוי יחול רק לאחר שההבטחה מוחזרת על ידי הפונקציה cookieStore.set מובילה.

await cookieStore.set({name: 'opt_out', value: '1'});

// undefined

לצפות, לא לערוך סקר

אפליקציה פופולרית לגישה לקובצי cookie מ-JavaScript מזהה מתי המשתמש מתנתק ומעדכנים את ממשק המשתמש. הפעולה הזו מתבצעת כרגע באמצעות סקרים document.cookie, תכונה שמציגה את ממשק המשתמש (jank) ומושפעת לרעה על הסוללה חיים.

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)

בגלל עיצוב סינכרוני, ה-API של document.cookie לא נוצר זמין ל- service worker. Cookie Store API הוא אסינכרוני ולכן הוא מותר בשירות ב-Google Workspace for Education.

האינטראקציה עם קובצי ה-cookie פועלת באותו אופן בהקשרים של מסמכים קובצי שירות (service worker).

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

עם זאת, יש הבדלים קלים בין השינויים בקובצי Cookie ב-Service Workers. השכמה קובץ שירות (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 specification repository, ולדווח על באגים בהטמעה Blink>Storage>CookiesAPI רכיב הבהוב.

אנחנו מעוניינים במיוחד ללמוד על מדידת ביצועים ועל השימוש במקרים אחרים מעבר לאלה שמתוארים בהסבר.