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

Victor Costan
X GitHub

מהו 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...

ה-API המצטיין של document.cookie הוא מקור מובטח למדי של jank לאפליקציה. לדוגמה, בכל פעם שמשתמשים ב-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>Storage>CookiesAPI ההבהוב.

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

מקורות מידע נוספים