از طریق Storage Access API در آزمایش اولیه برای دسترسی به فضای ذخیره‌سازی بدون کوکی شرکت کنید

هلن چو
Helen Cho
آری چیووکولا
Ari Chivukula
GitHub

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

سایت‌هایی که برای اجرای پشتیبانی از پارتیشن‌بندی ذخیره‌سازی شخص ثالث وقت نداشته‌اند، می‌توانند در یک آزمایش منسوخ برای لغو موقت پارتیشن‌سازی شرکت کنند (ایزوله‌سازی با خط‌مشی مبدأ یکسان ادامه یابد، اما جداسازی توسط سایت سطح بالا حذف شود) و رفتار قبلی را بازیابی کنند. ذخیره سازی، کارگران خدمات، و API های ارتباطی، در محتوای تعبیه شده در سایت آنها. این نسخه آزمایشی منسوخ قرار است با انتشار Chrome 127 در 3 سپتامبر 2024 منقضی شود. توجه داشته باشید که این نسخه آزمایشی منسوخ برای دسترسی به کوکی‌های شخص ثالث جدا است: این فقط برای دسترسی به فضای ذخیره‌سازی است.

به عنوان یک راه حل طولانی مدت برای رسیدگی به موارد استفاده خاص که توسط پارتیشن بندی فضای ذخیره سازی غیر کوکی شخص ثالث مختل شده است، Chrome این امکان را برای اشخاص ثالث پیشنهاد می کند که از طریق Storage Access API درخواست دسترسی به فضای ذخیره/ارتباطات (هم کوکی و هم غیرکوکی) کنند. ارسال از Chrome 117)، که در حال حاضر به اشخاص ثالث اجازه می دهد تا دسترسی به کوکی را درخواست کنند.

از Chrome 120، این پیشنهاد برای آزمایش از طریق آزمایش اولیه در دسترس خواهد بود. توسعه‌دهندگان باید در این آزمایش اولیه شرکت کنند تا ارزیابی کنند که چگونه راه‌حل پیشنهادی به موارد استفاده آنها می‌پردازد تا اطمینان حاصل شود که قبل از پایان دوره آزمایشی منسوخ شدن آماده شده‌اند.

جزئیات آزمایشی اصلی

از Chrome 120، Chrome از نسخه آزمایشی اصلی ، StorageAccessAPIBeyondCookies پشتیبانی می‌کند تا افزونه پیشنهادی Storage Access API (سازگار با عقب) را فعال کند تا امکان دسترسی به فضای ذخیره‌سازی پارتیشن نشده (کوکی و غیرکوکی) را در زمینه شخص ثالث فراهم کند.

مکانیک

API را می توان به صورت زیر استفاده کرد (جاوا اسکریپت در یک iframe تعبیه شده اجرا می شود):

// Request a new storage handle via rSA (this should prompt the user)
const handle = await document.requestStorageAccess({all: true});
// Write some 1P context sessionStorage
handle.sessionStorage.setItem('userid', '1234');
// Write some 1P context localStorage
handle.localStorage.setItem('preference', 'A');
// Open or create an indexedDB that is shared with the 1P context
const messageDB = handle.indexedDB.open('messages');
// Use locks shared with the 1P context
await handle.locks.request('example', ...);

اگر به جای دسترسی به all فقط دسترسی API خاصی را می خواهید، می توانید نام دسته های API مورد نیاز خود را ارسال کنید. برای مثال، می‌توانید {sessionStorage: true} را برای دسترسی به Session Storage یا {indexedDB: true, locks:true} برای دسترسی به IndexedDB و Web Locks عبور دهید.

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

مدت زمان

نسخه آزمایشی اصلی از Chrome 120 تا Chrome 125 (یا پس از 6 اوت 2024 در هر نقطه عطفی) در دسترس خواهد بود.

دامنه

فقط فضای ذخیره‌سازی DOM (جلسه و فضای ذخیره‌سازی محلی)، DB فهرست‌شده و قفل‌های وب در Chrome 120 موجود است.

حافظه پنهان، سیستم فایل خصوصی Origin، سهمیه، ذخیره‌سازی Blob و کانال پخش در Chrome 121 اضافه شد.

Shared Workers و کنترل بر گنجاندن کوکی‌ها در Chrome 123 اضافه شد.

اگر requestStorageAccess قبل از ایجاد کارگر در Chrome 120 فراخوانی شده باشد، کارگران اختصاصی دسترسی به کوکی‌های پارتیشن نشده را به ارث می‌برند (این کار نیازی به استفاده از دسته API دسترسی به فضای ذخیره‌سازی ندارد).

شرکت کنید

  1. نحوه استفاده از فضای ذخیره‌سازی کوکی و غیرکوکی را در زمینه شخص ثالث ارزیابی کنید. موارد استفاده مثال ممکن است به درک اینکه آیا این پیشنهاد ممکن است با نیازهای شما مطابقت داشته باشد یا خیر کمک کند.
  2. Chrome نسخه 120 (یا جدیدتر) را راه‌اندازی کنید و مطمئن شوید که پرچم تست شخص ثالث-کوکی مرحله‌ای فعال است.
  3. اگر می‌خواهید این ویژگی را به صورت محلی بدون تنظیم یک نشانه آزمایشی اولیه آزمایش کنید، می‌توانید #enable-experimental-web-platform-features را در مرورگر خود فعال کنید.
    1. پس از انجام آزمایش محلی، می توانید برای آزمایش اولیه StorageAccessAPIBeyondCookies ثبت نام کنید و یک توکن برای دامنه های خود دریافت کنید. برای دستورالعمل‌های دقیق‌تر، به «شروع با آزمایش‌های مبدا» مراجعه کنید. راهنمای عیب‌یابی آزمایش‌های اولیه Chrome یک چک لیست کامل برای اطمینان از پیکربندی صحیح رمز شما ارائه می‌کند.
    2. آن نشانه آزمایشی مبدا را در iframe جاسازی کنید تا از دستگیره API دسترسی به فضای ذخیره سازی در داخل آن استفاده کنید، با استفاده از هدر HTTP ، متا تگ HTML یا به صورت برنامه نویسی . توجه داشته باشید که نشانه باید توسط هر فریمی که مایل به استفاده از این API است جاسازی شود، جاسازی آن در قاب والد، API را در فریم های فرزند فعال نمی کند.
  4. با document.requestStorageAccess(...) تماس بگیرید تا دسته API دسترسی به فضای ذخیره سازی را در iframe بین سایتی دریافت کنید. برای اطلاع از الزامات موفقیت این تماس، به مستندات Storage Access API مراجعه کنید.
  5. فضای ذخیره سازی مربوط به iframe خود را برای استفاده از دستگیره API دسترسی به فضای ذخیره سازی در صورت موجود بودن منتقل کنید. برای مثال، فراخوانی های window.sessionStorage.setItem(...) تبدیل به handle.sessionStorage.setItem(...) می شود.
  6. وب سایت خود را باز کنید و بررسی کنید که دستگیره دسترسی به فضای ذخیره سازی همانطور که در نظر گرفته شده است کار می کند.
  7. برای توقف شرکت در آزمایش اولیه، رمزی را که در مرحله 3 اضافه کرده‌اید حذف کنید.
  8. بازخورد ارسال کنید یا هر مشکلی را که با آن مواجه می‌شوید در مخزن GitHub Storage Access API Non-Cookie Storage ارسال کنید.

نسخه ی نمایشی: با استفاده از Storage Access API برای دسترسی به Local Storage بدون پارتیشن

دمو زیر نحوه دسترسی به کانال‌های پخش بدون پارتیشن از iframe شخص ثالث را با استفاده از Storage Access API نشان می‌دهد:

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

نسخه ی نمایشی به Chrome 121 یا بالاتر با پرچم تست شخص ثالث-کوکی-فاصله فعال نیاز دارد.

منابع اضافی