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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

جزئیات ادغام مجموعه‌های وب‌سایت مرتبط

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

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

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

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

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

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

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

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

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

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

درخواست دسترسی به حافظه در کروم

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

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

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

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

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

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

دسترسی به برخی از ویژگی‌های مرورگر، مانند دوربین یا موقعیت مکانی، بر اساس مجوزهای اعطا شده توسط کاربر است. 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 کراس-اوریجینِ تعبیه‌شده

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

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

اگر مقدار promise برابر با 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
      }
    );
  }
}

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

سایت‌های سطح بالا که از طرف سایت‌های چند-مبدأی درخواست دسترسی به کوکی می‌کنند

سایت‌های سطح بالا می‌توانند از 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() ، درخواست‌های بین‌سایتی در صورت وجود 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
      });
  }

نحوه تست محلی

پیش‌نیازها

برای آزمایش مجموعه وب‌سایت‌های مرتبط به صورت محلی، از کروم ۱۱۹ یا بالاتر که از خط فرمان اجرا شده است استفاده کنید و پرچم کروم test-third-party-cookie-phaseout را فعال کنید.

فعال کردن پرچم کروم

برای فعال کردن فلگ مورد نیاز کروم، از نوار آدرس به chrome://flags#test-third-party-cookie-phaseout بروید و فلگ را به Enabled تغییر دهید. پس از تغییر فلگ‌ها، حتماً مرورگر را مجدداً راه‌اندازی کنید.

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

برای اجرای کروم با مجموعه وب‌سایت‌های مرتبط که به صورت محلی تعریف شده‌اند، یک شیء 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 فعال کنید و کروم را از خط فرمان با پرچم --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) را از سایت‌هایی که در حال آزمایش هستند فراخوانی کنید و دسترسی به کوکی‌های بین‌سایتی را تأیید کنید.

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

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

۱. نقاط حساس بدن (RWS) خود را شناسایی کنید

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

۲. ارسال RWS خود را ایجاد کنید

یک کپی محلی (کلون یا فورک) از مخزن GitHub ایجاد کنید. در یک شاخه جدید، تغییرات را در فایل related_website_sets.JSON ایجاد کنید تا مجموعه شما را منعکس کند. برای اطمینان از اینکه مجموعه شما قالب‌بندی و ساختار JSON مناسبی دارد، می‌توانید از ابزار JSON Generator استفاده کنید.

۳. اطمینان حاصل کنید که RWS شما الزامات فنی را برآورده می‌کند.

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

۴. RWS خود را به صورت محلی آزمایش کنید

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

۵. RWS خود را ارسال کنید

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

پس از ایجاد PR، مجموعه‌ای از بررسی‌ها انجام می‌شود تا اطمینان حاصل شود که الزامات مرحله ۳ رعایت شده‌اند، مانند اطمینان از اینکه CLA را امضا کرده‌اید و فایل .well-known معتبر است.

در صورت موفقیت، PR نشان می‌دهد که بررسی‌ها با موفقیت انجام شده‌اند. PRهای تأیید شده به صورت دستی و دسته‌ای، هفته‌ای یک بار (سه‌شنبه‌ها ساعت ۱۲ ظهر به وقت شرقی) در فهرست مجموعه وب‌سایت‌های مرتبط استاندارد ادغام می‌شوند. در صورت عدم موفقیت هر یک از بررسی‌ها، از طریق خرابی PR در GitHub به ارسال‌کننده اطلاع داده می‌شود. ارسال‌کننده می‌تواند خطاها را برطرف کرده و PR را به‌روزرسانی کند و به خاطر داشته باشد که:

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

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

کروم برای رفع نیازهای کاربران سازمانی دو سیاست در پیش گرفته است:

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

کروم هرگونه تداخل بین مجموعه‌های عمومی و سازمانی را بسته به اینکه آیا replacements یا additions مشخص شده باشد، به یکی از دو روش زیر حل می‌کند.

برای مثال، برای مجموعه عمومی {primary: A, associated: [B, C]} :

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

«دستور کاربر» و «اشاره کاربر»

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

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

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

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

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

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

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

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

• به فهرست پستی عمومی مجموعه وب‌سایت‌های مرتبط بپیوندید.
  • مشکلات خود را مطرح کنید و بحث را در مخزن گیت‌هاب مجموعه‌های وب‌سایت مرتبط دنبال کنید.