קבוצות אתרים קשורות: מדריך למפתחים

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

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

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

מהי קבוצת אתרים קשורים?

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

בדוגמה הבאה, primary מציג את הדומיין הראשי, ו-associatedSites מציג דומיינים שעומדים בדרישות של קבוצת המשנה המשויכת.

{
  "primary": "https://primary.com",
  "associatedSites": ["https://associate1.com", "https://associate2.com", "https://associate3.com"]
}

קבוצות של אתרים קשורים מפורטות בקובץ JSON ציבורי שמתארח ב-GitHub. זהו המקור הקנוני לכל הקבוצות שאושרו. הדפדפנים משתמשים בקובץ הזה כדי לקבוע אם אתרים שייכים לאותה קבוצה של אתרים קשורים.

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

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

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

תרחישים לדוגמה לשימוש בקבוצות של אתרים קשורים

קבוצות אתרים קשורים מתאימות למקרים שבהם לארגון יש צורך בזהות משותפת באתרים שונים ברמה העליונה.

כמה מהתרחישים לדוגמה לשימוש בקבוצות של אתרים קשורים:

• התאמה אישית לפי מדינה. ניצול אתרים מותאמים לשוק המקומי תוך שימוש בתשתית משותפת (example.co.uk יכול להסתמך על שירות שמתארח ב-example.ca).
• שילוב של דומיין שירות. ניצול דומיינים של שירותים שהמשתמשים אף פעם לא מקיימים איתם אינטראקציה ישירה, אבל מספקים שירותים באתרים של אותו ארגון (example-cdn.com).
• הפרדה בין תוכן של משתמשים. גישה לנתונים בדומיינים שונים שמפרידים תוכן שהמשתמשים העלו מתוכן אחר באתר מטעמי אבטחה, תוך מתן גישה לדומיין ב-sandbox לקובצי cookie לאימות (וקובצי cookie אחרים). אם אתם מציגים תוכן לא פעיל שהמשתמשים העלו, יכול להיות שתוכלו לארח אותו באותו דומיין בצורה בטוחה, אם תפעלו לפי השיטות המומלצות.
  • תוכן מוטמע מאומת. תמיכה בתוכן מוטמע מנכסים שמשויכים לאתר (סרטונים, מסמכים או משאבים שמוגבלים למשתמש שמחובר באתר ברמה העליונה).
• כניסה. תמיכה בכניסה לחשבון בנכסים שמשויכים לחשבון. FedCM API יכול להתאים גם לתרחישי שימוש מסוימים.
• Analytics. פריסה של ניתוח נתונים ומדידה של תהליכי השימוש של המשתמשים בנכסים שמשויכים אלינו, כדי לשפר את איכות השירותים.

פרטי השילוב של קבוצות של אתרים קשורים

Storage Access API

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

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

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

בדיקה ובקשה של גישה לאחסון

כדי לבדוק אם יש להם גישה לאחסון כרגע, אתרים מוטמעים יכולים להשתמש בשיטה Document.hasStorageAccess().

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

כדי לבקש גישה לקובצי cookie בהקשר של אתרים שונים, אתרים מוטמעים יכולים להשתמש ב-Document.requestStorageAccess() (rSA).

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

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

requestStorageAccessFor ב-Chrome

‏Storage Access API מאפשר לאתרים מוטמעים לבקש גישה לאחסון רק מתוך רכיבי <iframe> שקיבלו אינטראקציה מהמשתמש.

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

כדי לטפל בבעיה הזו, הוספנו ל-Chrome דרך שבה אתרים ברמה העליונה יכולים לבקש גישה לאחסון בשם מקורות ספציפיים באמצעות Document.requestStorageAccessFor() (rSAFor).

 document.requestStorageAccessFor('https://target.site')

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

בדיקת הרשאות הגישה לאחסון

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

אפשר לשלוח שאילתה לגבי סטטוס ההרשאה באמצעות navigator.permissions.query().

כדי לבדוק את הרשאת הגישה לאחסון בהקשר הנוכחי, צריך להעביר את המחרוזת 'storage-access':

navigator.permissions.query({name: 'storage-access'})

כדי לבדוק את הרשאת הגישה לאחסון למקור מסוים, צריך להעביר את המחרוזת 'top-level-storage-access':

navigator.permissions.query({name: 'top-level-storage-access', requestedOrigin: 'https://target.site'})

חשוב לזכור: כדי להגן על התקינות של המקור המוטמע, הבדיקה הזו בודקת רק את ההרשאות שהוקצו על ידי המסמך ברמה העליונה באמצעות document.requestStorageAccessFor.

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

מודל לפי מסגרת

הקצאות rSA חלות לכל פריים. הקצאות rSA ו-rSAFor נחשבות להרשאות נפרדות.

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

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

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

קובצי cookie חייבים לציין גם את המאפיינים SameSite=None וגם את המאפיינים Secure, כי rSA מספק גישה רק לקובצי cookie שכבר מסומנים לשימוש בהקשרים שונים באתרים.

קובצי cookie עם המאפיין SameSite=Lax, עם המאפיין SameSite=Strict או בלי המאפיין SameSite מיועדים לשימוש של צד ראשון בלבד, ואף פעם לא ישותפו בהקשר של כמה אתרים, ללא קשר ל-rSA.

אבטחה

ב-rSAFor, בקשות למשאבי משנה מחייבות כותרות שיתוף משאבים בין מקורות (CORS) או את המאפיין crossorigin במשאבים, כדי להבטיח הסכמה מפורשת.

דוגמאות להטמעה

שליחת בקשה לגישה לאחסון מ-iframe מוטמע חוצה-מקורות

איך בודקים אם יש לכם גישה לאחסון

כדי לבדוק אם כבר יש לכם גישה לאחסון, השתמשו ב-document.hasStorageAccess().

אם ההחלטה של ההבטחה היא true, תוכלו לגשת לאחסון בהקשר של האתרים השונים. אם הערך הוא false, צריך לבקש גישה לאחסון.

document.hasStorageAccess().then((hasAccess) => {
    if (hasAccess) {
      // You can access storage in this context
    } else {
      // You have to request storage access
    }
});

שליחת בקשה לגישה לאחסון

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

אם ההרשאה היא granted, אפשר להפעיל את document.requestStorageAccess() והיא אמורה לפעול ללא תנועת משתמש.

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

דוגמה:

navigator.permissions.query({name: 'storage-access'}).then(res => {
  if (res.state === 'granted') {
    // Permission has already been granted
    // You can request storage access without any user gesture
    rSA();
  } else if (res.state === 'prompt') {
    // Requesting storage access requires user gesture
    // For example, clicking a button
    const btn = document.createElement("button");
    btn.textContent = "Grant access";
    btn.addEventListener('click', () => {
      // Request storage access
      rSA();
    });
    document.body.appendChild(btn);
  }
});

function rSA() {
  if ('requestStorageAccess' in document) {
    document.requestStorageAccess().then(
      (res) => {
        // Use storage access
      },
      (err) => {
        // Handle errors
      }
    );
  }
}

לבקשות הבאות מתוך המסגרת, מהניווטים או מהמשאבים המשניים תהיה הרשאה אוטומטית לגשת לקובצי cookie בכמה אתרים. הפונקציה hasStorageAccess() מחזירה את הערך true, וקובצי cookie מאתרים שונים מאותו קבוצת אתרים קשורים יישלחו בבקשות האלה ללא קריאות JavaScript נוספות.

אתרים ברמה העליונה שמבקשים גישה לקובצי cookie בשם אתרים ממקורות שונים

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

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

כדי לבדוק אם תופיע בקשה למשתמש או אם כבר הוקצה גישה לאחסון למקור שצוין, צריך להפעיל את navigator.permissions.query({name: 'top-level-storage-access', requestedOrigin: 'https://target.site'}).

אם ההרשאה היא granted, אפשר לבצע את הקריאה document.requestStorageAccessFor('https://target.site'). הפעולה אמורה להתבצע ללא תנועת משתמש.

אם ההרשאה היא prompt, תצטרכו לקשר את הקריאה ל-document.requestStorageAccessFor('https://target.site') לתנועת המשתמש, כמו לחיצה על לחצן.

דוגמה:

navigator.permissions.query({name:'top-level-storage-access',requestedOrigin: 'https://target.site'}).then(res => {
  if (res.state === 'granted') {
    // Permission has already been granted
    // You can request storage access without any user gesture
    rSAFor();
  } else if (res.state === 'prompt') {
    // Requesting storage access requires user gesture
    // For example, clicking a button
    const btn = document.createElement("button");
    btn.textContent = "Grant access";
    btn.addEventListener('click', () => {
      // Request storage access
      rSAFor();
    });
    document.body.appendChild(btn);
  }
});

function rSAFor() {
  if ('requestStorageAccessFor' in document) {
    document.requestStorageAccessFor().then(
      (res) => {
        // Use storage access
      },
      (err) => {
        // Handle errors
      }
    );
  }
}

אחרי קריאה מוצלחת ל-requestStorageAccessFor(), בקשות בין אתרים יכללו קובצי cookie אם הן כוללות את CORS או את המאפיין crossorigin, לכן מומלץ לאתרים להמתין לפני שהם מפעילים בקשה.

בבקשות צריך להשתמש באפשרות credentials: 'include' והמשאבים צריכים לכלול את המאפיין crossorigin="use-credentials".

function checkCookie() {
    fetch('https://related-website-sets.glitch.me/getcookies.json', {
        method: 'GET',
        credentials: 'include'
      })
      .then((response) => response.json())
      .then((json) => {
      // Do something
      });
  }

איך בודקים באופן מקומי

דרישות מוקדמות

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

הפעלת הדגל ב-Chrome

כדי להפעיל את הדגל הנדרש של Chrome, עוברים לכתובת chrome://flags#test-third-party-cookie-phaseout מסרגל הכתובות ומשנים את הדגל ל-Enabled. חשוב להפעיל מחדש את הדפדפן אחרי שינוי הדגלים.

הפעלת Chrome עם קבוצה מקומית של אתרים קשורים

כדי להפעיל את Chrome עם קבוצת אתרים קשורים שהוגדרה באופן מקומי, יוצרים אובייקט JSON שמכיל כתובות URL שהן חברות בקבוצה ומעבירים אותו אל --use-related-website-set.

מידע נוסף על הפעלת Chromium עם דגלים

--use-related-website-set="{\"primary\": \"https://related-website-sets.glitch.me\", \"associatedSites\": [\"https://rws-member-1.glitch.me\"]}" \
https://related-website-sets.glitch.me/

דוגמה

כדי להפעיל 'קבוצות של אתרים קשורים' באופן מקומי, צריך להפעיל את הדגל test-third-party-cookie-phaseout בקובץ chrome://flags ולהפעיל את Chrome משורת הפקודה עם הדגל --use-related-website-set, יחד עם אובייקט ה-JSON שמכיל את כתובות ה-URL ששייכות לקבוצה.

--use-related-website-set="{\"primary\": \"https://related-website-sets.glitch.me\", \"associatedSites\": [\"https://rws-member-1.glitch.me\"]}" \
https://related-website-sets.glitch.me/

מוודאים שיש לכם גישה לקובצי cookie בכמה אתרים

קוראים לממשקי ה-API (rSA או rSAFor) מהאתרים שנבדקים ומאמתים את הגישה לקובצי ה-cookie בכמה אתרים.

תהליך השליחה של קבוצות של אתרים קשורים

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

1. זיהוי ה-RWS

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

2. יצירת בקשה להצטרפות ל-RWS

יוצרים עותק מקומי (העתקה או שיוך) של מאגר GitHub. בהסתעפות חדשה, מבצעים את השינויים בקובץ related_website_sets.JSON כך שישקפו את הקבוצה. כדי לוודא שהקבוצה שלכם בפורמט ובמבנה הנכונים של JSON, תוכלו להשתמש בכלי ליצירת קובצי JSON.

3. מוודאים שה-RWS עומד בדרישות הטכניות

מוודאים שהדרישות להגדרת קבוצה והדרישות לאימות קבוצה מתקיימות.

4. בדיקה מקומית של RWS

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

5. שליחת ה-RWS

שולחים את קבוצת האתרים הקשורים על ידי יצירת בקשת תיקון (PR) לקובץ related_website_sets.JSON, שבו Chrome מארח את הרשימה הקנונית של קבוצות האתרים הקשורים. (נדרש חשבון GitHub כדי ליצור בקשות תיקון, וצריך לחתום על הסכם רישיון של שותף (CLA) לפני שתוכלו לתרום לרשימת הבעיות).

אחרי יצירת הבקשה, מתבצעת סדרה של בדיקות כדי לוודא שהיא עומדת בדרישות של שלב 3, למשל לוודא שחתמתם על ה-CLA ושקובץ .well-known תקין.

אם הבדיקה תעבור, ב-PR יופיע סימן וי. בקשות תיקון שאושררו ימוזגו באופן ידני בקבוצות לרשימת קבוצות האתרים הקשורים הקנונית פעם בשבוע (ביום שלישי בשעה 12:00 לפי שעון החוף המזרחי). אם אחת מהבדיקות נכשלת, שולח הבקשה יקבל הודעה על כך ב-GitHub. שולחי הבקשה יכולים לתקן את השגיאות ולעדכן את הבקשה לבדיקה חוזרת. חשוב לזכור:

• אם ה-PR נכשל, תוצג הודעת שגיאה עם מידע נוסף על הסיבה לכך. (דוגמה).
• כל הבדיקות הטכניות שקשורות לשליחת ערכות מתבצעות ב-GitHub, ולכן כל הכישלונות בשליחה שנובעים מבדיקות טכניות יהיו גלויים ב-GitHub.

כללי מדיניות הארגון

ב-Chrome יש שתי מדיניות שמיועדות לענות על הצרכים של משתמשים ארגוניים:

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

Chrome פותר כל צומת של הקבוצות הציבוריות והארגוניות באחת משתי דרכים, בהתאם להגדרה של replacements או additions.

לדוגמה, עבור הקבוצה הציבורית {primary: A, associated: [B, C]}:

פתרון בעיות שקשורות לקבוצות של אתרים קשורים

'הנחיה למשתמש' ו'מחווה של משתמש'

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

גישה לקובצי cookie או לאחסון של אתרים אחרים

קבוצות של אתרים קשורים לא ממזגות את האחסון של אתרים שונים: הן רק מאפשרות לבצע בקלות רבה יותר קריאות ל-requestStorageAccess() (ללא הנחיה). קבוצות של אתרים קשורים רק מפחיתות את החיכוך של המשתמשים בשימוש ב-Storage Access API, אבל לא קובעות מה לעשות אחרי שהגישה תוחזר. אם א' וב' הם אתרים שונים באותה קבוצה של אתרים קשורים, וא' מוטמע ב-B, האתר B יכול לקרוא ל-requestStorageAccess() ולקבל גישה לאחסון מאינטראקציה ישירה בלי להציג בקשה למשתמש. קבוצות של אתרים קשורים לא מבצעות תקשורת בין אתרים. לדוגמה, הגדרת קבוצה של אתרים קשורים לא תגרום לכך שקובצי ה-cookie ששייכים לאתר ב' יתחילו להישלח לאתר א'. אם רוצים לשתף את הנתונים האלה, צריך לשתף אותם בעצמכם, למשל על ידי שליחת window.postMessage מ-iframe של B למסגרת של A.

גישה לקובצי cookie ללא חלוקה למחיצות כברירת מחדל

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

מתן משוב

שליחת קבוצה ב-GitHub ועבודה עם Storage Access API ו-requestStorageAccessFor API הן הזדמנויות לשתף את החוויה שלכם בתהליך ואת הבעיות שבהן נתקלת.

כדי להצטרף לדיוני קבוצות של אתרים קשורים:

• להצטרף לרשימת התפוצה הציבורית של קבוצות של אתרים קשורים.
  • אתם יכולים לדווח על בעיות ולעקוב אחרי הדיון במאגר GitHub של קבוצות של אתרים קשורים.