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

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

Victor Costan

מהו Cookie Store API?

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

כדי להימנע מתנודות ב-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 יש עלות גבוהה של ביצועים. הדפדפנים צריכים לכלול קובץ snapshot של קובצי ה-cookie בכל בקשת HTTP, כך שכל שינוי בקובצי ה-cookie צריך להופיע בכל שכבות האחסון והרשת. בדפדפנים מודרניים יש הטמעות אופטימליות של מאגרי קובצי cookie, אבל לעולם לא נוכל להפוך את קובצי ה-cookie ליעילים כמו מנגנוני האחסון האחרים, שלא צריכים לתקשר עם סטאק הרשת.

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

עם זאת, אם אתם עדיין קוראים את המאמר הזה, סימן שיש לכם סיבה טובה להשתמש בקובצי cookie…

קריאת קובץ cookie וחיסול תנודות לא רצויות

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

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

await cookieStore.get('session_id');

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

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

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

// undefined

תצפו, אל תערכו סקרים

אפליקציה פופולרית לגישה לקובצי cookie מ-JavaScript מזהה מתי המשתמש יוצא מהחשבון ומעדכנת את ממשק המשתמש. בשלב הזה, הבדיקה מתבצעת באמצעות סקרים של 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 workers) – ברוכים הבאים

בגלל העיצוב הסינכרוני, ה-API של document.cookie לא זמין ל-service workers. Cookie Store API הוא אסינכרוני, ולכן מותר להשתמש בו בשירותים של עובדים.

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

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

עם זאת, מעקב אחרי שינויים בקובצי cookie שונה במעט ב-service workers. ההפעלה של עובד שירות יכולה להיות די יקרה, לכן צריך לתאר בבירור את השינויים בקובצי ה-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‏ Blink>Storage>CookiesAPI.

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