גרסת טרום-השקה למקורות עם תמיכה בכותרות HTTP בגישה לאחסון

Natalia Markoborodova
Natalia Markoborodova
X GitHub תקלה

אנחנו מתחילים ב-Chrome גרסת מקור לניסיון להוספת כותרות HTTP ל-Storage Access API‏ (SAA) בגרסה 130: כותרות גישה לאחסון. הכותרת החדשה של הבקשה Sec-Fetch-Storage-Access והכותרת החדשה של התגובה Activate-Storage-Access נועדו לתמוך במשאבים שאינם iframe, ולשפר את הביצועים ואת חוויית המשתמש באתרים שמסתמכים על תוכן מוטמע, כמו ווידג'טים של רשתות חברתיות, יומנים וכלים אינטראקטיביים.

תהליך העבודה ב-JavaScript (והמגבלות שלו)

בעבר, כדי להשתמש ב-SAA נדרשה קריאה ל-JavaScript API אל document.requestStorageAccess() בכל טעינת מחדש, גם אם המשתמש כבר העניק הרשאה. השיטה הזו יעילה, אבל יש לה מגבלות:

  • מספר סבבים של הודעות חזרה ו forth ברשת: התהליך כלל בדרך כלל כמה בקשות לרשת וטעינות מחדש של דפים לפני שהתוכן המוטמע יכול היה לפעול באופן מלא.
  • תלות ב-iframe: כדי להריץ JavaScript, צריך להשתמש ב-iframe או במשאבי משנה בתוך iframe, מה שמגביל את הגמישות של המפתחים.

לדוגמה, ווידג'ט של יומן מ-calendar.example שמוטמע ב-website.example באמצעות JavaScript בלבד ייראה כך:

  1. טעינת placeholder: website.example מבקש את הווידג'ט. מכיוון שלווידג'ט calendar.example שמוטמע ב-website.example אין גישה לקובצי ה-cookie שלו שלא חולקו למחיצות, במקום זאת נערך עיבוד של ווידג'ט placeholder.
  2. בקשת הרשאה: ה-placeholder נטען, ולאחר מכן מתבצעת קריאה ל-document.requestStorageAccess() כדי לבקש הרשאה ל-storage-access.
  3. המשתמש בוחר להעניק הרשאה.
  4. טעינה מחדש של הווידג'ט: הווידג'ט יתעדכן, הפעם עם גישה לקובצי cookie, ובסופו של דבר התוכן המותאם אישית ייטען.
  5. בכל פעם שהמשתמש מבקר שוב באתר שמוטמע בו הווידג'ט calendar.example, התהליך זהה לזה שמתואר בשלבים 1, 2 ו-4. ההבדל היחיד הוא שהמשתמש לא צריך להעניק שוב גישה.

התהליך הזה לא יעיל: אם המשתמש כבר העניק הרשאת אחסון, אין צורך בעומס הראשוני של iframe, בקריאה ל-document.requestStorageAccess() ובטעינה מחדש לאחר מכן, והם יוצרים זמן אחזור.

התהליך החדש עם כותרות HTTP

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

כשמשתמשים בכותרות גישה לאחסון, הדפדפן יאתר באופן אוטומטי משאבים עם כותרת הבקשה Sec-Fetch-Storage-Access: inactive מוגדרת, אם המשתמש כבר העניק הרשאה. לא נדרשת פעולה מצד המפתחים כדי להגדיר את כותרת הבקשה. השרת יכול להשיב עם הכותרת Activate-Storage-Access: retry; allowed-origin="<origin>", והדפדפן ינסה שוב את הבקשה עם פרטי הכניסה הנדרשים.

כותרת הבקשה

Sec-Fetch-Storage-Access: <access-status>

כשמשתמש נכנס לדף שמוטמע בו תוכן מכמה אתרים, הדפדפן יכלול באופן אוטומטי את הכותרת Sec-Fetch-Storage-Access בבקשות מכמה אתרים שעשויות לדרוש פרטי כניסה (כמו קובצי cookie). הכותרת הזו מציינת את סטטוס הרשאת הגישה של קובץ ה-Cookie להטמעה. כך מפרשים את הערכים שלו:

  • none: לקוד ההטמעה אין את ההרשאה storage-access, ולכן אין לו גישה לקובצי cookie שלא חולקו למחיצות.
  • inactive: להטמעה יש את ההרשאה storage-access, אבל לא הבעת הסכמה לשימוש בה. להטמעה אין גישה לקובצי cookie ללא חלוקה למחיצות.
  • active: להטמעה יש גישה לקובצי cookie ללא חלוקה למחיצות. הערך הזה ייכלל בכל בקשות מאתרים שונים שיש להן גישה לקובצי cookie שלא חולקו למחיצות.

כותרות תגובה

Activate-Storage-Access: <retry-or-reload>

הכותרת Activate-Storage-Access מורה לדפדפן לנסות שוב את הבקשה עם קובצי cookie או לטעון את המשאב ישירות עם הפעלת SAA. הכותרת יכולה לקבל את הערכים הבאים:

  • load: מורה לדפדפן להעניק למטמיע גישה לקובצי cookie ללא חלוקה למחיצות עבור המשאב המבוקש.
  • retry: השרת משיב שהדפדפן צריך להפעיל את הרשאת הגישה לאחסון, ואז לנסות שוב את הבקשה.
Activate-Storage-Access: retry; allowed-origin="https://site.example"
Activate-Storage-Access: retry; allowed-origin=*
Activate-Storage-Access: load

תמיכה במשאבים שאינם iframe

העדכון של כותרות הגישה לאחסון מאפשר להשתמש ב-SAA בתוכן מוטמע שאינו iframe, כמו תמונות שמתארחות בדומיין אחר. בעבר, אף ממשק API של פלטפורמת אינטרנט לא איפשר לטעון משאבים כאלה עם פרטי כניסה בדפדפנים אם קובצי cookie של צד שלישי לא זמינים. לדוגמה, ה-embedding-site.example יכול לבקש תמונה:

   <img src="https://server.example/image"/>

והשרת יכול להגיב עם תוכן או שגיאה, בהתאם לכך אם קובץ cookie זמין:

app.get('/image', (req, res) => {
  const headers = req.headers;
  const cookieHeader = headers.cookie;
  // Check if the embed has the necessary cookie access
  if (!cookieHeader || !cookieHeader.includes('foo')) {
  // If the cookie is not present, check if the browser supports Storage Access headers
    if (
      'sec-fetch-storage-access' in headers &&
      headers['sec-fetch-storage-access'] == 'inactive'
    ) {
    // If the browser supports Storage Access API, retry the request with storage access enabled
      res.setHeader('Activate-Storage-Access', 'retry; allowed-origin="https://embedding-site.example"');
    }
    res.status(401).send('No cookie!');
   } else {
    // If the cookie is available, check if the user is authorized to access the image
    if (!check_authorization(cookieHeader)) {
      return res.status(401).send('Unauthorized!');
    }
    // If the user is authorized, respond with the image file
    res.sendFile("path/to/image.jpeg");
  }
});

אם קובץ ה-cookie לא זמין, השרת בודק את הערך של כותרת הבקשה Sec-Fetch-Storage-Access. אם הערך הזה מוגדר כ-inactive, השרת משיב עם הכותרת Activate-Storage-Access: retry, שמציינת שצריך לנסות שוב את הבקשה עם גישה לאחסון. אם אין קובץ cookie ובכותרת Sec-Fetch-Storage-Access לא מופיע הערך inactive, התמונה לא תיטען.

תהליך העברת כותרות HTTP

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

כשמשתמשים בכותרות של גישה לאחסון, הביקורים בדפים הבאים יפעילו את התהליך הבא:

  1. המשתמש מבקר שוב ב-website.example שבו מוטמע ה-calendar.example. לאחזור הזה עדיין אין גישה לקובץ ה-cookie, כמו קודם. עם זאת, המשתמש העניק בעבר הרשאה storage-access, והאחזור כולל כותרת Sec-Fetch-Storage-Access: inactive כדי לציין שגישה לקובצי cookie ללא חלוקה למחיצות זמינה אבל לא בשימוש.
  2. שרת calendar.example משיב עם כותרת Activate-Storage-Access: retry; allowed-origin="<origin>" (במקרה הזה, <origin> יהיה https://website.example), כדי לציין שהאחזור של המשאב מחייב שימוש בקובצי cookie ללא חלוקה למחיצות עם הרשאת גישה לאחסון.
  3. הדפדפן מנסה שוב את הבקשה, הפעם כולל קובצי cookie שלא חולקו למחיצות (הפעלת ההרשאה storage-access לאחזור הזה).
  4. השרת calendar.example מגיב עם תוכן ה-iframe המותאם אישית. התשובה כוללת כותרת Activate-Storage-Access: load כדי לציין שהדפדפן צריך לטעון את התוכן עם ההרשאה storage-access מופעלת (כלומר, טעינה עם גישה לקובצי cookie ללא חלוקה למחיצות, כאילו הופעלה document.requestStorageAccess()).
  5. סוכן המשתמש טוען את תוכן ה-iframe עם גישה לקובצי cookie ללא חלוקה למחיצות באמצעות הרשאת הגישה לאחסון. אחרי השלב הזה, הווידג'ט אמור לפעול כצפוי.
תרשים זרימה שממחיש את התהליך של כותרת הגישה לאחסון
תרשים תהליך של כותרת גישה לאחסון.

עדכון הפתרון

כשמשתמשים בתכונה 'כותרות גישה לאחסון', כדאי לעדכן את הקוד בשני מקרים:

  1. אתם משתמשים ב-SAA ואתם רוצים לשפר את הביצועים באמצעות לוגיקה של כותרות.
  2. יש לכם אימות או לוגיקה שמשתנה בהתאם לכך שכותרת Origin כלולה בבקשה בשרת.

הטמעת לוגיקה של כותרות SAA

כדי להשתמש בכותרות גישה לאחסון בפתרון שלכם, עליכם לעדכן את הפתרון. נניח שאתם הבעלים של calendar.example. כדי ש-website.example יוכל לטעון ווידג'ט calendar.example מותאם אישית, לקוד הווידג'ט צריכה להיות גישה לאחסון.

בצד הלקוח

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

בצד השרת

בצד השרת, אפשר להשתמש בכותרות החדשות:

app.get('/cookie-access-endpoint', (req, res) => {
  const storageAccessHeader = req.headers['sec-fetch-storage-access'];

  if (storageAccessHeader === 'inactive') {
    // User needs to grant permission, trigger a prompt
    if (!validate_origin(req.headers.origin)) {
      res.status(401).send(`${req.headers.origin} is not allowed to send` +
          ' credentialed requests to this server.');
      return;
    }
    res.set('Activate-Storage-Access', `retry; allowed-origin="${req.headers.origin}"`);
    res.status(401).send('This resource requires storage access. Please grant permission.');
  } else if (storageAccessHeader === 'active') {
    // User has granted permission, proceed with access
    res.set('Activate-Storage-Access', 'load');
    // Include the actual iframe content here
    res.send('This is the content that requires cookie access.');
  } else {
    // Handle other cases (e.g., 'Sec-Fetch-Storage-Access': 'none')
  }
});

בדקו את ההדגמה כדי לראות איך הפתרון הזה פועל בפועל.

עדכון הלוגיקה של כותרת המקור

כשמשתמשים בכותרות של גישה לאחסון, Chrome שולח את הכותרת Origin בבקשות רבות יותר מבעבר. הדבר עשוי להשפיע על הלוגיקה בצד השרת אם היא מסתמכת על כך שכותרת Origin תופיע רק בסוגים ספציפיים של בקשות (כמו אלה שמוגדרות על ידי CORS).

כדי למנוע בעיות אפשריות, צריך לבדוק את הקוד בצד השרת:

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

יתרונות מרכזיים

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

  • תמיכה בהטמעות שאינן iframe: מאפשרת להשתמש ב-SAA במגוון רחב יותר של משאבים.
  • צמצום השימוש ברשת: פחות בקשות ופחות עומסי נתונים.
  • שימוש נמוך יותר במעבד: פחות עיבוד של JavaScript.
  • חוויית משתמש משופרת: אין יותר עומסי ביניים שמפריעים.

השתתפות בתוכנית הניסוי למקורות

גרסאות מקור לניסיון מאפשרות לכם לנסות תכונות חדשות ולתת משוב על נוחות השימוש, הפרקטיות והיעילות שלהן. מידע נוסף זמין במאמר תחילת העבודה עם ניסויים במקור.

אתם יכולים לנסות את התכונה 'כותרות גישה לאחסון' על ידי הרשמה לגרסת הבטא של המקור, החל מגרסת Chrome 130. כדי להשתתף בתוכנית הניסיון למקורות:

  1. עוברים לדף הרישום לגרסת הטרום של Storage Access Headers.
  2. פועלים לפי ההוראות להשתתפות בתוכנית הניסוי למקורות.

בדיקה מקומית

אתם יכולים לבדוק את התכונה 'כותרות גישה לאחסון' באופן מקומי כדי לוודא שהאתר שלכם מוכן לשינוי הזה.

כדי להגדיר את מכונה של Chrome:

  1. מפעילים את הדגל של Chrome ב-chrome://flags/#storage-access-headers.
  2. כדי שהשינויים ייכנסו לתוקף, צריך להפעיל מחדש את Chrome.

יצירת מעורבות ושיתוף משוב

אם יש לכם משוב או נתקלתם בבעיות, אתם יכולים לדווח על בעיה. מידע נוסף על כותרות הגישה לאחסון זמין במאמר ההסבר ב-GitHub.