این صفحه به‌وسیله ‏Cloud Translation API‏ ترجمه شده است.

مجموعه‌های وب‌سایت مرتبط: راهنمای توسعه‌دهنده

مجموعه‌های وب‌سایت مرتبط (RWS) یک مکانیسم پلتفرم وب است که به مرورگرها کمک می‌کند تا روابط بین مجموعه‌ای از دامنه‌ها را درک کنند. این به مرورگرها اجازه می دهد تا تصمیمات کلیدی را برای فعال کردن عملکردهای سایت خاص (مانند اجازه دسترسی به کوکی های بین سایتی) و ارائه این اطلاعات به کاربران اتخاذ کنند.

از آنجایی که Chrome کوکی‌های شخص ثالث را منسوخ می‌کند، هدف آن حفظ موارد استفاده کلیدی در وب و در عین حال بهبود حریم خصوصی برای کاربران است. به عنوان مثال، بسیاری از سایت ها برای ارائه یک تجربه کاربری به چندین دامنه متکی هستند. سازمان‌ها ممکن است بخواهند دامنه‌های مختلف سطح بالا را برای موارد استفاده چندگانه مانند دامنه‌های خاص کشور یا دامنه‌های خدماتی برای میزبانی تصاویر یا ویدیوها حفظ کنند. Related Website Sets به سایت‌ها اجازه می‌دهد تا داده‌ها را در دامنه‌ها با کنترل‌های خاص به اشتراک بگذارند.

مجموعه وب سایت مرتبط چیست؟

در سطح بالا، یک مجموعه وب‌سایت مرتبط مجموعه‌ای از دامنه‌ها است که برای آن یک «مجموعه اولیه» و «عضو مجموعه» بالقوه متعدد وجود دارد.

در مثال زیر، primary دامنه اصلی را فهرست می‌کند و associatedSites دامنه‌هایی را فهرست می‌کند که الزامات زیرمجموعه مرتبط را برآورده می‌کنند.

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

فهرست متعارف Related Website Sets فهرستی است که برای عموم قابل مشاهده است در قالب فایل JSON که در مخزن Related Website Sets GitHub میزبانی می شود، که به عنوان منبع حقیقت برای همه مجموعه ها عمل می کند. کروم این فایل را مصرف می کند تا در رفتار آن اعمال شود.

فقط کسانی که کنترل مدیریتی روی یک دامنه دارند می توانند مجموعه ای با آن دامنه ایجاد کنند. ارسال کنندگان باید رابطه بین هر "عضو مجموعه" را با "مجموعه اولیه" خود اعلام کنند. اعضای مجموعه می توانند طیفی از انواع دامنه های مختلف را شامل شوند و باید بر اساس یک مورد استفاده بخشی از یک زیر مجموعه باشند.

اگر برنامه شما به دسترسی به کوکی‌های بین‌سایتی (که کوکی‌های شخص ثالث نیز نامیده می‌شود) در سراسر سایت‌های موجود در یک مجموعه وب‌سایت مرتبط بستگی دارد، می‌توانید از Storage Access API (SAA) و requestStorageAccessFor API برای درخواست دسترسی به آن کوکی‌ها استفاده کنید. بسته به زیرمجموعه ای که هر سایت بخشی از آن است، مرورگر ممکن است درخواست را به گونه ای متفاوت مدیریت کند.

برای کسب اطلاعات بیشتر در مورد فرآیند و الزامات ارسال مجموعه، دستورالعمل های ارسال را بررسی کنید. مجموعه‌های ارسالی از طریق بررسی‌های فنی مختلف برای تأیید اعتبار ارسالی‌ها انجام می‌شوند.

موارد استفاده مجموعه های وب سایت مرتبط

مجموعه‌های وب‌سایت مرتبط با مواردی که سازمان به نوعی هویت مشترک در سایت‌های سطح بالا نیاز دارد، مناسب است.

برخی از موارد استفاده برای مجموعه های وب سایت مرتبط عبارتند از:

سفارشی سازی کشور استفاده از سایت های محلی سازی شده در حالی که به زیرساخت های مشترک تکیه می کنید (example.co.uk ممکن است به سرویسی که توسط example.ca میزبانی می شود متکی باشد).
ادغام دامنه خدمات استفاده از دامنه‌های خدماتی که کاربران هرگز مستقیماً با آن‌ها تعامل ندارند، اما خدماتی را در سایت‌های همان سازمان ارائه می‌کنند (example-cdn.com).
جداسازی محتوای کاربر دسترسی به داده‌هایی در دامنه‌های مختلف که محتوای آپلود شده توسط کاربر را به دلایل امنیتی از سایر محتوای سایت جدا می‌کند، در حالی که به دامنه سندباکس امکان دسترسی به کوکی‌های احراز هویت (و دیگر) را می‌دهد. اگر محتوای آپلود شده توسط کاربر غیرفعال را ارائه می‌دهید، ممکن است بتوانید با پیروی از بهترین شیوه‌ها، آن را با خیال راحت در همان دامنه میزبانی کنید.
محتوای تایید شده تعبیه شده پشتیبانی از محتوای جاسازی شده از همه دارایی های وابسته (ویدئوها، اسناد، یا منابع محدود به کاربری که در سایت سطح بالا وارد شده است).
ورود . پشتیبانی از ورود به سیستم در دارایی های وابسته. FedCM API همچنین ممکن است برای برخی موارد استفاده مناسب باشد.
تجزیه و تحلیل . استقرار تجزیه و تحلیل و اندازه گیری سفرهای کاربر در دارایی های وابسته برای بهبود کیفیت خدمات.

وب سایت مرتبط جزئیات یکپارچه سازی را تنظیم می کند

Storage Access API

پشتیبانی مرورگر

119
85
65
11.1

منبع

Storage Access API (SAA) راهی را برای محتوای متقابل جاسازی شده برای دسترسی به فضای ذخیره‌سازی که معمولاً فقط در یک زمینه شخص اول به آن دسترسی دارد، فراهم می‌کند.

منابع جاسازی شده می‌توانند از روش‌های SAA برای بررسی اینکه آیا در حال حاضر به فضای ذخیره‌سازی دسترسی دارند یا خیر، و درخواست دسترسی از عامل کاربر، استفاده کنند.

وقتی کوکی‌های شخص ثالث مسدود می‌شوند اما مجموعه‌های وب‌سایت مرتبط (RWS) فعال است، Chrome به‌طور خودکار در زمینه‌های درون RWS مجوز می‌دهد و در غیر این صورت درخواستی را به کاربر نشان می‌دهد. («متن درون RWS» یک زمینه است، مانند یک iframe که سایت تعبیه شده و سایت سطح بالا در همان RWS هستند.)

بررسی و درخواست دسترسی به فضای ذخیره سازی

برای بررسی اینکه آیا در حال حاضر به فضای ذخیره‌سازی دسترسی دارند، سایت‌های جاسازی شده می‌توانند از روش Document.hasStorageAccess() استفاده کنند.

این روش یک وعده را برمی‌گرداند که با یک مقدار بولی که نشان می‌دهد آیا سند قبلاً به کوکی‌های خود دسترسی دارد یا خیر حل می‌شود. در صورتی که iframe با فریم بالایی یکسان باشد، وعده true برمی گردد.

برای درخواست دسترسی به کوکی ها در یک زمینه بین سایتی، سایت های تعبیه شده می توانند از Document.requestStorageAccess() (rSA) استفاده کنند.

API requestStorageAccess() باید از داخل یک iframe فراخوانی شود. آن iframe باید به تازگی تعامل کاربر را دریافت کرده باشد ( ژست کاربر ، که توسط همه مرورگرها مورد نیاز است)، اما Chrome علاوه بر این نیاز دارد که در مقطعی در 30 روز گذشته، کاربر از سایتی که مالک آن iframe است بازدید کرده و با آن تعامل داشته باشد. آن سایت به طور خاص — به عنوان یک سند سطح بالا، نه در iframe.

requestStorageAccess() قولی را برمی‌گرداند که در صورت اعطای دسترسی به فضای ذخیره‌سازی حل می‌شود. اگر به هر دلیلی از دسترسی منع شده باشد، قول با ذکر دلیل مردود است.

requestStorageAccessFor در کروم

پشتیبانی مرورگر

119
119
ایکس
ایکس

منبع

Storage Access API فقط به سایت های تعبیه شده اجازه می دهد تا از عناصر <iframe> که تعامل کاربر را دریافت کرده اند، درخواست دسترسی به فضای ذخیره سازی کنند.

این امر چالش‌هایی را در اتخاذ API دسترسی به فضای ذخیره‌سازی برای سایت‌های سطح بالایی که از تصاویر متقاطع سایت یا برچسب‌های اسکریپت نیاز به کوکی استفاده می‌کنند، ایجاد می‌کند.

برای رسیدگی به این موضوع، 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 به درخواست دسترسی مجدد نیاز دارد.

الزامات کوکی

کوکی ها باید هر دو ویژگی SameSite=None و Secure را مشخص کنند زیرا rSA فقط برای کوکی هایی که قبلاً برای استفاده در زمینه های بین سایتی علامت گذاری شده اند دسترسی می دهد .

کوکی‌هایی با SameSite=Lax ، SameSite=Strict ، یا بدون ویژگی SameSite فقط برای استفاده شخص اول هستند و هرگز بدون در نظر گرفتن rSA در یک زمینه بین سایتی به اشتراک گذاشته نمی‌شوند.

امنیت

برای rSAFor، درخواست‌های زیرمنبع به سربرگ‌های اشتراک‌گذاری منابع متقاطع (CORS) یا ویژگی crossorigin روی منابع نیاز دارند که از انتخاب صریح اطمینان حاصل می‌کند.

نمونه های پیاده سازی

درخواست دسترسی به فضای ذخیره سازی از یک iframe متقاطع تعبیه شده

نموداری که یک سایت تعبیه شده را در یک سایت سطح بالا نشان می دهد — استفاده از `requestStorageAccess()` در جاسازی در سایتی دیگر.

بررسی کنید که آیا به فضای ذخیره‌سازی دسترسی دارید یا خیر

برای بررسی اینکه آیا از قبل دسترسی به فضای ذخیره‌سازی دارید، از document.hasStorageAccess() استفاده کنید.

اگر وعده درست حل شود، می توانید به فضای ذخیره سازی در زمینه بین سایتی دسترسی داشته باشید. اگر خطا برطرف شد، باید درخواست دسترسی به فضای ذخیره سازی کنید.

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() آغاز کنید.

توجه: اگر قبل از اعطای مجوز یا ثبت ژست کاربر، درخواست requestStorageAccess() فراخوانی کنید، با خطا مواجه می‌شوید: "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
      }
    );
  }
}

درخواست‌های بعدی از داخل فریم، پیمایش‌ها یا منابع فرعی، به طور خودکار مجوز دسترسی به کوکی‌های بین سایتی را خواهند داشت. hasStorageAccess() درستی را برمی‌گرداند و کوکی‌های بین‌سایتی از همان مجموعه وب‌سایت مرتبط بدون هیچ فراخوانی اضافی جاوا اسکریپت برای آن درخواست‌ها ارسال می‌شوند.

سایت‌های سطح بالا که از طرف سایت‌های متقاطع درخواست دسترسی به کوکی می‌کنند

نموداری که نشان می دهد requestStorageAccessFor() در یک سایت سطح بالا استفاده می شود و نه در یک جاسازی — استفاده از `requestStorageAccessFor()` در یک سایت سطح بالا برای یک منبع متفاوت

سایت‌های سطح بالا می‌توانند از requestStorageAccessFor() برای درخواست دسترسی به ذخیره‌سازی از طرف مبداهای خاص استفاده کنند.

hasStorageAccess() فقط بررسی می‌کند که آیا سایتی که آن را فراخوانی می‌کند به ذخیره‌سازی دسترسی دارد، بنابراین یک سایت سطح بالا می‌تواند مجوزها را برای منبع دیگری بررسی کند.

برای کشف اینکه آیا از کاربر خواسته می شود یا اینکه دسترسی به فضای ذخیره سازی قبلاً به مبدأ مشخص داده شده است، با navigator.permissions.query({name: 'top-level-storage-access', requestedOrigin: 'https://target.site'}) تماس بگیرید 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() ، درخواست‌های بین‌سایتی در صورت داشتن 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://flags#test-third-party-cookie-phaseout بروید و پرچم را به Enabled تغییر دهید. مطمئن شوید که پس از تغییر پرچم ها، مرورگر را مجددا راه اندازی کنید.

Chrome را با یک مجموعه وب سایت مرتبط محلی راه اندازی کنید

برای راه‌اندازی Chrome با Related Website Set به صورت محلی، یک شی 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/

مثال

برای فعال کردن Related Website Sets به صورت محلی، باید 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/

بررسی کنید که به کوکی های بین سایتی دسترسی دارید

APIها (rSA یا rSAFor) را از سایت‌هایی که در حال آزمایش هستند تماس بگیرید و دسترسی به کوکی‌های بین سایتی را تأیید کنید.

فرآیند ارسال مجموعه های وب سایت مرتبط

برای اعلام رابطه بین دامنه ها و تعیین اینکه آنها بخشی از کدام زیر مجموعه هستند، مراحل زیر را دنبال کنید:

دامنه های مربوطه را شناسایی کنید، این شامل مجموعه اعضای اصلی و مجموعه است که بخشی از مجموعه وب سایت مرتبط خواهند بود. همچنین مشخص کنید که هر یک از اعضای مجموعه به کدام نوع زیر مجموعه تعلق دارد.
مطمئن شوید که الزامات تشکیل مجموعه و الزامات اعتبارسنجی مجموعه وجود دارند.
مجموعه وب سایت مرتبط را با فرمت JSON صحیح اعلام کنید.
مجموعه وب‌سایت مرتبط را با ایجاد یک درخواست کشش (PR) به related_website_sets.JSON ارسال کنید، جایی که Chrome فهرست متعارف مجموعه وب‌سایت‌های مرتبط را میزبانی می‌کند. (یک حساب GitHub برای ایجاد PR مورد نیاز است و برای مشارکت در لیست باید یک قرارداد مجوز مشارکت کننده (CLA) را امضا کنید.)

هنگامی که PR ایجاد شد، یک سری بررسی ها برای تأیید اینکه الزامات مرحله 2 وجود دارد، اتفاق می افتد.

در صورت موفقیت آمیز بودن، PR نشان می دهد که چک ها پاس شده اند. PRهای تأیید شده به صورت دستی به صورت دسته‌ای در فهرست مجموعه‌های وب‌سایت مرتبط متعارف یک بار در هفته (سه‌شنبه‌ها ساعت 12 بعد از ظهر به وقت شرقی) ادغام می‌شوند.

اگر هر یک از بررسی ها ناموفق باشد، ارسال کننده از طریق شکست روابط عمومی در GitHub مطلع می شود. ارسال کننده می تواند خطاها را برطرف کرده و روابط عمومی را به روز کند و در نظر داشته باشد که:

هنگامی که PR با شکست مواجه می شود، یک پیام خطا اطلاعات بیشتری در مورد اینکه چرا ارسال ممکن است ناموفق باشد ارائه می دهد ( مثال ).
تمام بررسی‌های فنی حاکم بر ارسال‌های مجموعه در GitHub انجام می‌شود، و در نتیجه همه شکست‌های ارسالی ناشی از بررسی‌های فنی در GitHub قابل مشاهده خواهند بود.

سیاست های سازمانی

برای رفع نیازهای کاربران سازمانی، Chrome چند خط‌مشی سازمانی دارد:

سیستم‌هایی که ممکن است نتوانند با مجموعه‌های وب‌سایت مرتبط ادغام شوند، می‌توانند ویژگی مجموعه‌های وب‌سایت مرتبط را در همه نمونه‌های سازمانی Chrome با خط‌مشی RelatedWebsiteSetsEnabled غیرفعال کنند.
برخی از سیستم‌های سازمانی فقط سایت‌های داخلی (مانند اینترانت) با دامنه‌های قابل ثبت دارند که با دامنه‌های موجود در مجموعه وب‌سایت مرتبط آنها متفاوت است. اگر لازم است این سایت ها را به عنوان بخشی از مجموعه وب سایت های مرتبط خود بدون افشای عمومی آنها در نظر بگیرند (از آنجایی که دامنه ها ممکن است محرمانه باشند)، می توانند لیست مجموعه های وب سایت های مرتبط عمومی خود را با خط مشی RelatedWebsiteSetsOverrides افزایش دهند یا لغو کنند.

عیب یابی مجموعه های وب سایت مرتبط

"User Prompt" و "User gesture"

«اعلان کاربر» و «ژست کاربر» چیزهای متفاوتی هستند. Chrome برای سایت‌هایی که در همان مجموعه وب‌سایت مرتبط هستند ، درخواست مجوز را به کاربران نشان نمی‌دهد، اما Chrome همچنان نیاز دارد که کاربر با صفحه تعامل داشته باشد. قبل از اعطای مجوز، Chrome به یک اشاره کاربر نیاز دارد که «تعامل کاربر» یا «فعال‌سازی کاربر» نیز نامیده می‌شود. این به این دلیل است که استفاده از Storage Access در خارج از زمینه مجموعه وب‌سایت مرتبط (یعنی requestStorageAccess() ) به دلیل اصول طراحی پلت فرم وب ، به ژست کاربر نیز نیاز دارد.

به کوکی ها یا فضای ذخیره سازی سایت های دیگر دسترسی داشته باشید

مجموعه‌های وب‌سایت مرتبط، فضای ذخیره‌سازی را برای سایت‌های مختلف ادغام نمی‌کند: فقط به تماس‌های requestStorageAccess() ساده‌تر (بدون درخواست) اجازه می‌دهد. مجموعه‌های وب‌سایت مرتبط تنها اصطکاک کاربر در استفاده از Storage Access API را کاهش می‌دهد، اما دیکته نمی‌کند که پس از بازیابی دسترسی، چه کاری انجام دهید. اگر A و B سایت‌های متفاوتی در یک مجموعه وب‌سایت مرتبط هستند و A در B را جاسازی می‌کند، B می‌تواند requestStorageAccess() را فراخوانی کند و بدون درخواست از کاربر به فضای ذخیره‌سازی شخص اول دسترسی داشته باشد. Related Website Sets هیچ ارتباط بین سایتی را انجام نمی دهد. برای مثال، راه‌اندازی یک مجموعه وب‌سایت مرتبط باعث نمی‌شود که کوکی‌های متعلق به B به A ارسال شوند. اگر می‌خواهید آن داده‌ها را به اشتراک بگذارید، باید خودتان آن‌ها را به اشتراک بگذارید، برای مثال با ارسال یک window.postMessage از یک فریم B به یک قاب A.

دسترسی به کوکی بدون پارتیشن به طور پیش فرض

Related Website Sets اجازه دسترسی ضمنی به کوکی بدون پارتیشن بندی بدون فراخوانی هیچ API را نمی دهد. کوکی های بین سایتی به طور پیش فرض در مجموعه موجود نیستند. Related Website Sets فقط به سایت‌های موجود در مجموعه اجازه می‌دهد از درخواست مجوز Storage Access API صرفنظر کنند . اگر یک iframe می‌خواهد به کوکی‌هایش دسترسی پیدا کند باید document.requestStorageAccess() را فراخوانی کند، یا صفحه سطح بالا می‌تواند document.requestStorageAccessFor() را فراخوانی کند.

بازخورد را به اشتراک بگذارید

ارسال مجموعه‌ای در GitHub و کار با Storage Access API و requestStorageAccessFor API فرصت‌هایی برای به اشتراک گذاشتن تجربه خود در مورد فرآیند و هر مشکلی است که با آن مواجه می‌شوید.

برای پیوستن به بحث‌های مربوط به مجموعه‌های وب‌سایت مرتبط:

به لیست پستی عمومی مجموعه های وب سایت مرتبط بپیوندید.
مسائل را مطرح کنید و بحث را در مورد مجموعه های وب سایت مرتبط مخزن GitHub دنبال کنید.