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

Natalia Markoborodova

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

תהליך JavaScript (וההגבלות שלו)

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

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

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

1. טעינת פלייסלודר: 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

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

אם המשתמש כבר העניק הרשאה, הדפדפן יביא באופן אוטומטי משאבים עם כותרת הבקשה Sec-Fetch-Storage-Access: inactive מוגדרת באמצעות כותרות Storage Access. לא נדרשת פעולה מצד המפתחים כדי להגדיר את כותרת הבקשה. השרת יכול להגיב עם הכותרת 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 שלא מחולקים למחיצות במהלך ביקורים עתידיים.

כשמשתמשים בכותרות Storage Access, הביקורים בדפים הבאים יפעילו את התהליך הבא:

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, לקוד הווידג'ט צריכה להיות גישה לאחסון.

בצד הלקוח

התכונה Storage Access Headers לא מחייבת עדכון קוד בצד הלקוח עבור הפתרונות הקיימים. בתיעוד מוסבר איך להטמיע 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')
  }
});

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

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

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

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

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

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

מומלץ להשתמש ב-SAA באמצעות כותרות Storage Access, כי זו דרך יעילה יותר. בסך הכול, השינוי הזה מביא איתו כמה שיפורים:

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

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

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

אתם יכולים לנסות את התכונה Storage Access Headers (כותרות גישה לאחסון) על ידי הרשמה לתקופות הניסיון של מקורות שמתחילות מ-Chrome 130. כדי להשתתף בגרסת המקור לניסיון:

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

בדיקה מקומית

אתם יכולים לבדוק את התכונה Storage Access Headers באופן מקומי כדי לוודא שהאתר שלכם מוכן לשינוי הזה.

כדי להגדיר את מופע Chrome:

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

אינטראקציה ושיתוף משוב

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