Storage Access API

חסימה של קובצי Cookie של צד שלישי על ידי דפדפנים, הגדרות משתמשים וחלוקת אחסון, יוצרת בעיה לאתרים ולשירותים שמסתמכים על קובצי Cookie ואחסון אחר בהקשרים מוטמעים, למסלולי משתמשים כמו אימות. ‫Storage Access API‏ (SAA) מאפשר לתרחישי השימוש האלה להמשיך לפעול, תוך הגבלת המעקב חוצה-האתרים ככל האפשר.

סטטוס ההטמעה

‫Storage Access API זמין בכל הדפדפנים המובילים, אבל יש הבדלים קלים בהטמעה בין הדפדפנים. ההבדלים האלה מודגשים בסעיפים הרלוונטיים בפוסט הזה.

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

מה זה Storage Access API?

‫Storage Access API הוא JavaScript API שמאפשר ל-iframe לבקש הרשאות גישה לאחסון, במקרים שבהם הגישה הייתה נדחית בגלל הגדרות הדפדפן. אם יש הטמעות שתרחישי השימוש שלהן תלויים בטעינה של משאבים מאתרים שונים, אפשר להשתמש ב-API כדי לבקש מהמשתמש הרשאת גישה לפי הצורך.

אם בקשת הגישה לאחסון מאושרת, ל-iframe תהיה גישה לקובצי ה-Cookie ולאחסון שלא מחולקים למחיצות, שזמינים גם כשמשתמשים מבקרים בו כאתר ברמה העליונה.

‫Storage Access API מאפשר לספק גישה ספציפית לקובצי Cookie ולאחסון שלא מחולקים למחיצות, עם מינימום עומס על משתמש הקצה, ובמקביל למנוע גישה כללית לקובצי Cookie ולאחסון שלא מחולקים למחיצות, כפי שקורה לעיתים קרובות כשעוקבים אחרי משתמשים.

תרחישים לדוגמה

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

תרחישים לדוגמה:

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

ברוב תרחישי השימוש האלה נדרשת התמדה של גישת ההתחברות ב-iframe מוטמע.

מתי כדאי להשתמש ב-Storage Access API במקום בממשקי API אחרים

‫Storage Access API הוא אחת מהחלופות לשימוש בקובצי Cookie ובאחסון שלא מחולקים למחיצות, ולכן חשוב להבין מתי כדאי להשתמש בממשק ה-API הזה בהשוואה לממשקי API אחרים. היא מיועדת לתרחישי שימוש שבהם מתקיימים שני התנאים הבאים:

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

יש ממשקי API חלופיים למגוון תרחישי שימוש:

• קובצי Cookie עם חלוקה עצמאית למחיצות (CHIPS) מאפשרים למפתחים להפעיל את האפשרות 'חלוקה למחיצות' לקובץ Cookie, עם מאגר נפרד של קובצי Cookie לכל אתר ברמה העליונה. לדוגמה, יכול להיות שווידג'ט של צ'אט באינטרנט של צד שלישי יסתמך על הגדרת קובץ Cookie כדי לשמור מידע על הפעילות. פרטי הסשן נשמרים לכל אתר בנפרד, כך שאין צורך לגשת לקובץ ה-Cookie שהווידג'ט מגדיר באתרים אחרים שבהם הוא מוטמע. ‫Storage Access API שימושי כשווידג'ט מוטמע של צד שלישי תלוי בשיתוף של אותו מידע בין מקורות שונים (לדוגמה, פרטי סשן של משתמשים מחוברים או העדפות).
• חלוקה למחיצות (partitioning) באחסון היא דרך שמאפשרת ל-iframes חוצי-אתרים להשתמש במנגנוני אחסון קיימים של JavaScript, תוך חלוקת האחסון הבסיסי לפי אתר. כך נמנעת גישה לאחסון מוטמע באתר אחד על ידי אותו תוכן מוטמע באתרים אחרים.
• קבוצות של אתרים קשורים (RWS) הן דרך שבה ארגון יכול להצהיר על קשרים בין אתרים, כדי שהדפדפנים יאפשרו גישה מוגבלת לקובצי Cookie ולאחסון שלא מחולקים למחיצות למטרות ספציפיות. אתרים עדיין צריכים לבקש גישה באמצעות Storage Access API, אבל לאתרים שכלולים בקבוצה אפשר לתת גישה בלי להציג למשתמשים הנחיות.
• ‫Federated Credential Management ‏ (FedCM) הוא גישה לשמירה על הפרטיות בשירותי זהויות מאוחדים. ‫Storage Access API מאפשר גישה לקובצי Cookie ולאחסון שלא מחולקים למחיצות אחרי שהמשתמש מתחבר לחשבון. במקרים מסוימים, FedCM מספק פתרון חלופי ל-Storage Access API, ויכול להיות שעדיף להשתמש בו כי הוא כולל הנחיה בדפדפן שמתמקדת יותר בהתחברות. עם זאת, כדי להטמיע את FedCM בדרך כלל צריך לבצע שינויים נוספים בקוד, למשל כדי לתמוך בנקודות הקצה של HTTP.
• קיימים גם ממשקי API למניעת הונאות, למודעות ולמדידה, ו-Storage Access API לא נועד לטפל בבעיות האלה.

שימוש ב-Storage Access API

ל-Storage Access API יש שתי שיטות מבוססות-הבטחה:

• ‫Document.hasStorageAccess() (זמין גם בשם החדש Document.hasUnpartitionedCookieAccess() החל מ-Chrome 125)
• Document.requestStorageAccess()

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

• navigator.permissions.query({name: "storage-access"});

שימוש בשיטה hasStorageAccess()

כשהאתר נטען בפעם הראשונה, הוא יכול להשתמש בשיטה hasStorageAccess() כדי לבדוק אם כבר ניתנה גישה לקובצי Cookie של צד שלישי.

// Set a hasAccess boolean variable which defaults to false.
let hasAccess = false;

async function handleCookieAccessInit() {
  if (!document.hasStorageAccess) {
    // Storage Access API is not supported so best we can do is
    // hope it's an older browser that doesn't block 3P cookies.
    hasAccess = true;
  } else {
    // Check whether access has been granted using the Storage Access API.
    hasAccess = await document.hasStorageAccess();
    if (!hasAccess) {
      // Handle the lack of access (covered later)
    }
  }
  if (hasAccess) {
    // Use the cookies.
  }
}
handleCookieAccessInit();

‫Storage Access API מעניק גישה לאחסון רק למסמך iframe אחרי שהוא קורא ל-requestStorageAccess(),. לכן, יכול להיות ש-hasStorageAccess() תחזיר false בהתחלה, למשל אם המשתמש חוסם קובצי Cookie של צד שלישי כברירת מחדל. (עם זאת, הגדרות משתמש ספציפיות לאתר עשויות גם לאפשר גישה לקובצי Cookie באתר מסוים, גם אם המשתמש חוסם קובצי Cookie של צד שלישי כברירת מחדל). הגישה לאחסון באמצעות ה-API הזה נשמרת במהלך מעברים באותו מקור בתוך ה-iframe, במיוחד כדי לאפשר טעינה מחדש אחרי מתן גישה לדפים שנדרשים קובצי Cookie כדי שיהיו נוכחים בבקשה הראשונית למסמך ה-HTML.

שימוש ב-requestStorageAccess()

אם ל-iframe אין גישה, יכול להיות שהוא יצטרך לבקש גישה באמצעות השיטה requestStorageAccess():

if (!hasAccess) {
  try {
    await document.requestStorageAccess();
  } catch (err) {
    // Access was not granted and it may be gated behind an interaction
    return;
  }
}

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

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

async function doClick() {

  // Only do this extra check if access hasn't already been given
  // based on the hasAccess variable.
  if (!hasAccess) {
    try {
      await document.requestStorageAccess();
      hasAccess = true; // Can assume this was true if requestStorageAccess() did not reject.
    } catch (err) {
      // Access was not granted.
      return;
    }
  }

  if (hasAccess) {
    // Use the cookies
  }
}

document.querySelector('#my-button').addEventListener('click', doClick);

הנחיות לבקשת הרשאה

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

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

• אם הדף וה-iframe היו בשימוש ב-30 הימים האחרונים אחרי שהמשתמש אישר את ההודעה.
• אם ה-iframe המוטמע הוא חלק מקבוצת אתרים קשורים.
• אם נעשה שימוש ב-FedCM כאות מהימנות לגישה לאחסון.
• ב-Firefox, ההנחיה גם לא מוצגת באתרים מוכרים (שקיימת אינטראקציה איתם ברמה העליונה) בחמש הפעמים הראשונות.

לחלופין, יכול להיות שהשיטה תידחה באופן אוטומטי בלי שההנחיה תוצג בנסיבות מסוימות:

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

בשימוש הראשוני, המשתמש יקבל הנחיה, אבל בביקורים הבאים אפשר יהיה לפתור את הבעיה requestStorageAccess() בלי הנחיה ובלי שהמשתמש יצטרך לבצע פעולה ב-Chrome וב-Firefox. שימו לב שב-Safari תמיד נדרשת אינטראקציה של המשתמש.

יכול להיות שתינתן גישה לקובצי Cookie ולאחסון בלי להציג בקשה או בלי שהמשתמש יבצע אינטראקציה. לכן, לעיתים קרובות אפשר לקבל גישה לקובצי Cookie ולאחסון שלא מחולקים למחיצות לפני שהמשתמש מבצע אינטראקציה בדפדפנים שתומכים בכך (Chrome ו-Firefox) על ידי קריאה ל-requestStorageAccess() בטעינת הדף. יכול להיות שהגישה לקובצי Cookie ולאחסון שלא מחולקים למחיצות תתאפשר באופן מיידי, ותוכלו לספק חוויה מלאה יותר עוד לפני שהמשתמש יצור אינטראקציה עם ה-iframe. במקרים מסוימים, חוויית המשתמש תהיה טובה יותר אם לא יצטרכו לחכות לאינטראקציה של המשתמש.

‫FedCM כאות אמון ב-SAA

‫FedCM (ניהול אישורים מאוחד) הוא גישה לשמירה על הפרטיות בשירותי זהויות מאוחדים (כמו 'כניסה באמצעות...') שלא מסתמכת על קובצי Cookie של צד שלישי או על הפניות אוטומטיות.

כשמשתמש מתחבר לאתר (Relying Party,‏ RP) שמוטמע בו תוכן מסוים מספק זהויות (IdP) של צד שלישי באמצעות FedCM, התוכן המוטמע של ספק הזהויות יכול לקבל באופן אוטומטי גישה לאחסון של קובצי ה-Cookie שלו ברמה העליונה שלא חולקו למחיצות. כדי להפעיל גישה אוטומטית לאחסון באמצעות FedCM, צריך לעמוד בתנאים הבאים:

• אימות FedCM (מצב הכניסה של המשתמש) צריך להיות פעיל.
• ספק הזהויות הצטרף על ידי הגדרת ההרשאה identity-credentials-get, לדוגמה:

<iframe src="https://idp.example" allow="identity-credentials-get"></iframe>

לדוגמה, iframe של idp.example מוטמע ב-rp.example. כשהמשתמש מתחבר באמצעות FedCM, ‏ idp.example iframe יכול לבקש גישה לאחסון של קובצי ה-Cookie שלו ברמה העליונה.

האתר rp.example מבצע קריאה ל-FedCM כדי להכניס את המשתמש לחשבון באמצעות ספק הזהויות idp.example:

// The user will be asked to grant FedCM permission.
const cred = await navigator.credentials.get({
  identity: {
    providers: [{
      configURL: 'https://idp.example/fedcm.json',
      clientId: '123',
    }],
  },
});

אחרי שהמשתמש מתחבר, ספק ה-IdP יכול לקרוא ל-requestStorageAccess() מתוך ה-iframe של idp.example, כל עוד ספק ה-RP אישר זאת באופן מפורש באמצעות Permissions Policy. הגישה לאחסון של קובץ ה-Cookie ברמה העליונה של ההטמעה תינתן באופן אוטומטי, בלי שהמשתמש יצטרך להפעיל אותה או בלי שתוצג בקשת הרשאה נוספת:

// Make this call within the embedded IdP iframe:

// No user gesture is needed, and the storage access will be auto-granted.
await document.requestStorageAccess();

// This returns `true`.
const hasAccess = await document.hasStorageAccess();

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

‫Storage Access API לאחסון שאינו קובץ Cookie

כדי לבקש גישה לאחסון מקומי לא מחולק, צריך להעביר את הפרמטר types לקריאה ל-requestStorageAccess. לדוגמה, כדי לבקש גישה לאחסון מקומי שלא מחולק למחיצות, אפשר לקרוא ל-requestStorageAccess({localStorage: true}).

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

קודם כול בודקים אם לדפדפן כבר יש גישה לאחסון:

async function hasCookieAccess(){
  // Check if Storage Access API is supported
  if (!document.requestStorageAccess) {
    // Storage Access API is not supported, so we assume it's an older browser that doesn't partition storage.
    throw new Error("requestStorageAccess is not supported")
  }

  // Check if access has already been granted or if the user has 3-party cookies enabled
  return document.hasStorageAccess();
}

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

// Request storage access and return the storage handle
async function requestStorageHandle(){
// You can request for multiple types of non-cookie storage
// at once, or request for all of them with all:true
return document.requestStorageAccess({all:true});
}

אם קובצי Cookie של צד שלישי חסומים (לדוגמה, במצב פרטי), צריך לבדוק את הרשאות השאילתה כדי להחליט אם נדרשת הנחיה למשתמש. מצב ההרשאה navigator.permissions.query({name: 'storage-access'}) יכול לקבל את הערכים הבאים:

• granted. המשתמש כבר העניק גישה. התקשרות אל requestStorageAccess כדי לקבל גישה לאחסון לא מחולק בלי צורך בהנחיה נוספת למשתמש.
• prompt. המשתמש עדיין לא העניק גישה. מגדירים מאזין לקליקים ומפעילים את הפונקציה requestStorageAccess שוב אחרי אינטראקציה של המשתמש.
• error. ההרשאה לא נתמכת. אם יש תמיכה ב-Storage Access API, סביר להניח שיש תמיכה גם בהרשאה הזו.

// Returns `granted`, or `prompt`; or throws an error if storage-access
// permission is not supported
async function getStorageAccessPermission(){
  // Check the storage-access permission
  // Wrap this in a try/catch for browsers that support the
  // Storage Access API but not this permission check
    return navigator.permissions.query({name: 'storage-access'});
}

אפשר להטמיע את התהליך המלא לטיפול באחסון מחולק שאינו קובץ Cookie באופן הבא:

async function getStorageHandle() {
    // Check if the user has 3-party cookie access
    if (await hasCookieAccess()) {
    // If the user has access, requestStorageAccess() will resolve automatically
        return requestStorageHandle();
    }

    // If the browser blocks third party cookies, check if the user has
    // accepted the prompt and granted access. If they have,
    // requestStorageAccess() will resolve automatically
    const permission = await getStorageAccessPermission();
    if (permission == 'granted') { // User has seen prompt and granted access
        return requestStorageHandle();
    }

    // Wait for user activation to prompt the user again
    // (or put your silent failure logic here instead)
    return new Promise((resolve, reject) => {
        document.querySelector('#myButton').addEventListener(e => {
            requestStorageHandle().then(resolve, reject);
        })
    })
}

// Use your storage
getStorageHandle().then(handle=>{
    handle.indexedDB.open(...);
}).catch(() => {
    // If the promise is rejected, you can use regular partitioned storage
    indexedDB.open(...);
})

טעינה לאחר מכן באמצעות כותרות Storage Access

השימוש בכותרות Storage Access הוא דרך מומלצת ויעילה יותר להטמעת תוכן, כולל משאבים שאינם מסוג iframe. התכונה זמינה מגרסה 133 של Chrome. באמצעות כותרות של גישה לאחסון, הדפדפן יכול לזהות מתי המשתמש כבר העניק ל-storage-access הרשאה למקור של צד שלישי בהקשר הנוכחי, ויכול לטעון משאבים עם גישה לקובצי Cookie שלא חולקו למחיצות במהלך ביקורים עוקבים.

תהליך של כותרות גישה לאחסון

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

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

שימוש בכותרות של גישה לאחסון

בטבלה הבאה מפורטות כותרות של גישה לאחסון.

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

  // On the client side
  <img src="https://server.example/image">

במקרה כזה, server.example צריך להטמיע את הלוגיקה הבאה בצד השרת:

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

  if (storageAccessHeader === 'inactive') {
    // The user needs to grant permission, trigger a prompt

    // Check if the requesting origin is allowed
    // to send credentialed requests to this server.
    // Assuming the `validate_origin(origin)` method is previously defined:
    if (!validate_origin(req.headers.origin)) {
      res.status(401).send(req.headers.origin +
        ' is not allowed to send credentialed requests to this server.');
      return;
    }
    // 'retry' header value indicates that the content load request should be re-sent after the user has granted permissions
    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')
  }
});

הדמו של Storage Access API מטמיע תוכן של צד שלישי (כולל תמונה שאינה iframe) באמצעות כותרות של Storage Access.

שימוש באילתת ההרשאות storage-access

כדי לבדוק אם אפשר להעניק גישה בלי אינטראקציה של המשתמש, אפשר לבדוק את הסטטוס של ההרשאה storage-access ולהפעיל את השיחה requestStoreAccess() מוקדם רק אם לא נדרשת פעולת משתמש, במקום להפעיל אותה ולגלות שהיא נכשלת כשנדרשת אינטראקציה.

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

הקוד הבא מוסיף את בדיקת ההרשאה storage-access לדוגמה הקודמת:

// Set a hasAccess boolean variable which defaults to false except for
// browsers which don't support the API - where we assume
// such browsers also don't block third-party cookies.
let hasAccess = false;

async function hasCookieAccess() {
  // Check if Storage Access API is supported
  if (!document.requestStorageAccess) {
    // Storage Access API is not supported so best we can do is
    // hope it's an older browser that doesn't block 3P cookies.
    return true;
  }

  // Check if access has already been granted
  if (await document.hasStorageAccess()) {
    return true;
  }

  // Check the storage-access permission
  // Wrap this in a try/catch for browsers that support the
  // Storage Access API but not this permission check
  // (e.g. Safari and earlier versions of Firefox).
  let permission;
  try {
    permission = await navigator.permissions.query(
      {name: 'storage-access'}
    );
  } catch (error) {
    // storage-access permission not supported. Assume no cookie access.
    return false;
  }

    if (permission) {
    if (permission.state === 'granted') {
      // Permission has previously been granted so can just call
      // requestStorageAccess() without a user interaction and
      // it will resolve automatically.
      try {
        await document.requestStorageAccess();
        return true;
      } catch (error) {
        // This shouldn't really fail if access is granted, but return false
        // if it does.
        return false;
      }
    } else if (permission.state === 'prompt') {
      // Need to call requestStorageAccess() after a user interaction
      // (potentially with a prompt). Can't do anything further here,
      // so handle this in the click handler.
      return false;
          } else if (permission.state === 'denied') {
            // Not used: see https://github.com/privacycg/storage-access/issues/149
      return false;
          }
    }

  // By default return false, though should really be caught by earlier tests.
  return false;
}

async function handleCookieAccessInit() {
  hasAccess = await hasCookieAccess();

  if (hasAccess) {
    // Use the cookies.
  }
}

handleCookieAccessInit();

Sandboxed iframes

כשמשתמשים ב-Storage Access API בiframe עם ארגז חול, נדרשות הרשאות ארגז החול הבאות:

• נדרשת הרשאה של allow-storage-access-by-user-activation כדי לאפשר גישה ל-Storage Access API.
• נדרשת הרשאה לשימוש ב-JavaScript כדי להפעיל את ה-API.allow-scripts
• נדרש allow-same-origin כדי לאפשר גישה לקובצי Cookie ולאמצעי אחסון אחרים מאותו מקור.

לדוגמה:

<iframe sandbox="allow-storage-access-by-user-activation
                 allow-scripts
                 allow-same-origin"
        src="..."></iframe>

דרישות לגבי קובצי Cookie

כדי שיהיה אפשר לגשת לקובצי Cookie חוצי-אתרים באמצעות Storage Access API ב-Chrome, צריך להגדיר אותם עם שני המאפיינים הבאים:

• ‫SameSite=None – נדרש כדי לסמן את קובץ ה-Cookie כקובץ חוצה-אתרים
• ‫Secure – כדי לוודא שרק קובצי Cookie שהוגדרו על ידי אתרי HTTPS יוכלו להיות נגישים.

בדפדפנים Firefox ו-Safari, קובצי Cookie מוגדרים כברירת מחדל כ-SameSite=None, והם לא מגבילים את SAA לקובצי Cookie מסוג Secure, ולכן המאפיינים האלה לא נדרשים. מומלץ להשתמש במאפיין SameSite באופן מפורש ולהשתמש תמיד בקובצי Cookie מסוג Secure.

גישה לדף ברמה העליונה

ה-API לגישה לאחסון מיועד להפעלת גישה לקובצי Cookie של צד שלישי בתוך מסגרות iframe מוטמעות.

יש גם תרחישי שימוש אחרים שבהם הדף ברמה העליונה דורש גישה לקובצי Cookie של צד שלישי. לדוגמה, תמונות או סקריפטים שמוגבלים על ידי קובצי Cookie, שבעלי אתרים עשויים לרצות לכלול ישירות במסמך ברמה העליונה ולא ב-iframe. כדי לטפל בתרחיש השימוש הזה, ב-Chrome הוצע הרחבה ל-Storage Access API שמוסיפה את השיטהrequestStorageAccessFor().

השיטה requestStorageAccessFor()

השיטה requestStorageAccessFor() פועלת באופן דומה לשיטה requestStorageAccess(), אבל היא מיועדת למשאבים ברמה העליונה. אפשר להשתמש בה רק באתרים שנכללים בקבוצה של אתרים קשורים, כדי למנוע מתן גישה כללית לקובצי Cookie של צד שלישי.

מידע נוסף על השימוש ב-requestStorageAccessFor() זמין במדריך למפתחים בנושא קבוצות של אתרים קשורים.

שאילתת ההרשאות top-level-storage-access

בדומה להרשאה storage-access, יש הרשאה top-level-storage-access לבדיקה אם אפשר להעניק גישה ל-requestStorageAccessFor().

מה ההבדל בשימוש ב-Storage Access API בשילוב עם RWS?

כשמשתמשים בקבוצות של אתרים קשורים בשילוב עם Storage Access API, יש אפשרויות נוספות שזמינות, כמו שמפורט בטבלה הבאה:

הדגמה: הגדרה וגישה לקובצי Cookie

ההדגמה הבאה מראה איך אפשר לגשת לקובץ Cookie שהגדרתם בעצמכם במסך הראשון של ההדגמה, במסגרת מוטמעת באתר השני של ההדגמה:

storage-access-api-demo.glitch.me

כדי להשתמש בהדגמה צריך דפדפן שבו קובצי Cookie של צד שלישי מושבתים:

• ‫Chrome 118 ואילך עם הגדרת הדגל chrome://flags/#test-third-party-cookie-phaseout והפעלה מחדש של הדפדפן.
• Firefox
• Safari

הדגמה: הגדרת אחסון מקומי

בהדגמה הבאה אפשר לראות איך ניגשים לערוצי שידור לא מחולקים למחיצות מ-iframe של צד שלישי באמצעות Storage Access API:

https://saa-beyond-cookies.glitch.me/

כדי להשתמש בהדגמה צריך Chrome מגרסה 125 ואילך, עם הדגל test-third-party-cookie-phaseout מופעל.

משאבים

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