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

آزمایش اولیه برای پشتیبانی از هدر HTTP در دسترسی به فضای ذخیره سازی

Natalia Markoborodova

Chrome در حال شروع یک آزمایش اولیه برای افزودن سرصفحه‌های HTTP به API دسترسی به فضای ذخیره‌سازی (SAA) در نسخه 130 است: سرصفحه‌های دسترسی به فضای ذخیره‌سازی . هدر جدید درخواست Sec-Fetch-Storage-Access و هدر پاسخ Activate-Storage-Access پشتیبانی از منابع غیرiframe و بهبود عملکرد و تجربه کاربر برای وب‌سایت‌هایی که به محتوای جاسازی‌شده متکی هستند، مانند ویجت‌های رسانه‌های اجتماعی، تقویم‌ها و ابزارهای تعاملی است.

جریان جاوا اسکریپت (و محدودیت های آن)

پیش از این، SAA به یک فراخوانی API جاوا اسکریپت برای document.requestStorageAccess() در هر بارگذاری مجدد نیاز داشت، حتی اگر کاربر قبلاً مجوز داده باشد. در حالی که موثر است، این روش محدودیت هایی را معرفی می کند:

رفت و برگشت چندگانه شبکه: این فرآیند اغلب شامل چندین درخواست شبکه و بارگیری مجدد صفحه قبل از اینکه محتوای تعبیه شده به طور کامل کار کند، می شود.
وابستگی به Iframe: اجرای جاوا اسکریپت استفاده از iframe یا منابع فرعی را در iframe الزامی می کند و انعطاف پذیری را برای توسعه دهندگان محدود می کند.

برای مثال، یک ویجت تقویم از calendar.example که در website.example تنها با استفاده از جاوا اسکریپت جاسازی شده است، به شکل زیر است:

یک مکان نگهدار را بارگیری کنید: website.example ویجت را درخواست می کند. از آنجایی که ویجت calendar.example تعبیه شده در website.example به کوکی های پارتیشن نشده خود دسترسی ندارد، در عوض یک ویجت مکان نگهدار ارائه می شود.
درخواست مجوز: محل نگهدارنده بارگیری می شود، سپس document.requestStorageAccess() را برای درخواست مجوز storage-access فراخوانی می کند.
کاربر اعطای مجوز را انتخاب می کند .
ویجت را دوباره بارگذاری کنید: ویجت، این بار با دسترسی به کوکی، تازه می شود و در نهایت محتوای شخصی شده را بارگیری می کند.
هر بار که کاربر از سایتی بازدید می کند که ویجت calendar.example را دوباره جاسازی می کند، جریان دقیقاً مانند مراحل 1، 2 و 4 به نظر می رسد. تنها ساده سازی این است که کاربر نیازی به اعطای مجدد دسترسی ندارد.

این جریان ناکارآمد است: اگر کاربر قبلاً مجوز ذخیره سازی داده باشد، بارگذاری اولیه iframe، فراخوانی document.requestStorageAccess() و بارگذاری مجدد بعدی غیرضروری می شود و تأخیر ایجاد می کند.

جریان جدید با هدرهای HTTP

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

با Storage Access Headers، مرورگر به طور خودکار منابع را با Sec-Fetch-Storage-Access: inactive واکشی می کند، اگر کاربر قبلاً مجوز داده باشد. برای تنظیم سرصفحه درخواست نیازی به اقدام توسعه دهنده نیست. سرور می تواند با Activate-Storage-Access پاسخ دهد Activate-Storage-Access: retry; allowed-origin="<origin>" هدر Activate-Storage-Access: retry; allowed-origin="<origin>" و مرورگر درخواست را با اعتبار لازم دوباره امتحان می کند.

سربرگ درخواست

Sec-Fetch-Storage-Access: <access-status>

وقتی کاربر از صفحه ای بازدید می کند که محتوای بین سایتی را جاسازی می کند، مرورگر به طور خودکار سرصفحه Sec-Fetch-Storage-Access را در درخواست های بین سایتی که ممکن است به اعتبارنامه نیاز داشته باشند (مانند کوکی ها) اضافه می کند. این هدر وضعیت مجوز دسترسی به کوکی جاسازی را نشان می دهد. در اینجا نحوه تفسیر مقادیر آن آمده است:

none : جاسازی مجوز storage-access را ندارد و بنابراین به کوکی های پارتیشن نشده دسترسی ندارد.
inactive : جاسازی دارای مجوز storage-access است، اما استفاده از آن را انتخاب نکرده است. جاسازی دسترسی به کوکی بدون پارتیشن ندارد.
active : جاسازی دسترسی به کوکی بدون پارتیشن دارد. این مقدار در درخواست‌های متقاطع که به کوکی‌های پارتیشن نشده دسترسی دارند، لحاظ می‌شود.

سرصفحه های پاسخ

Activate-Storage-Access: <retry-or-reload>

هدر Activate-Storage-Access به مرورگر دستور می دهد تا درخواست را با کوکی ها دوباره امتحان کند یا منبع را مستقیماً با SAA فعال شده بارگیری کند. هدر می تواند مقادیر زیر را داشته باشد:

load : به مرورگر دستور می دهد تا به embedder اجازه دسترسی به کوکی های پارتیشن نشده برای منبع درخواستی بدهد.
retry : سرور پاسخ می دهد که مرورگر باید مجوز دسترسی به ذخیره سازی را فعال کند، سپس درخواست را دوباره امتحان کنید.

Activate-Storage-Access: retry; allowed-origin="https://site.example"
Activate-Storage-Access: retry; allowed-origin=*
Activate-Storage-Access: load

پشتیبانی از منابع غیر iframe

به‌روزرسانی سرصفحه‌های دسترسی به فضای ذخیره‌سازی، SAA را برای محتوای تعبیه‌شده بدون iframe، مانند تصاویری که در دامنه‌های دیگری میزبانی می‌شوند، فعال می‌کند. قبلاً، هیچ API پلتفرم وب اجازه بارگیری چنین منابعی را با اعتبارنامه ها در مرورگرها در صورت در دسترس نبودن کوکی های شخص ثالث، نمی داد. به عنوان مثال، embedding-site.example شما می تواند یک تصویر درخواست کند:

   <img src="https://server.example/image"/>

و سرور می تواند با محتوا یا خطا، بسته به اینکه یک کوکی در دسترس باشد، پاسخ دهد:

app.get('/image', (req, res) => {
  const headers = req.headers;
  const cookieHeader = headers.cookie;
  // Check if the embed has the necessary cookie access
  if (!cookieHeader || !cookieHeader.includes('foo')) {
  // If the cookie is not present, check if the browser supports Storage Access headers
    if (
      'sec-fetch-storage-access' in headers &&
      headers['sec-fetch-storage-access'] == 'inactive'
    ) {
    // If the browser supports Storage Access API, retry the request with storage access enabled
      res.setHeader('Activate-Storage-Access', 'retry; allowed-origin="https://embedding-site.example"');
    }
    res.status(401).send('No cookie!');
   } else {
    // If the cookie is available, check if the user is authorized to access the image
    if (!check_authorization(cookieHeader)) {
      return res.status(401).send('Unauthorized!');
    }
    // If the user is authorized, respond with the image file
    res.sendFile("path/to/image.jpeg");
  }
});

اگر کوکی در دسترس نباشد، سرور مقدار هدر درخواست Sec-Fetch-Storage-Access بررسی می کند. اگر این مقدار روی inactive تنظیم شود، سرور با سربرگ Activate-Storage-Access: retry پاسخ می دهد، که نشان می دهد درخواست باید با دسترسی به فضای ذخیره سازی دوباره امتحان شود. اگر کوکی وجود نداشته باشد و هدر Sec-Fetch-Storage-Access دارای مقدار غیرفعال نباشد، تصویر بارگیری نمی شود.

جریان سرصفحه HTTP

با هدرهای HTTP، مرورگر می‌تواند تشخیص دهد که کاربر قبلاً مجوز دسترسی به ذخیره‌سازی را به ویجت داده است و iframe را با دسترسی به کوکی‌های پارتیشن نشده در بازدیدهای بعدی بارگیری کند.

با سربرگ‌های دسترسی به فضای ذخیره‌سازی، بازدیدهای بعدی از صفحات جریان زیر را آغاز می‌کنند:

کاربر از website.example بازدید می کند که calendar.example دوباره جاسازی کرده است. این واکشی مانند قبل هنوز به کوکی دسترسی ندارد. با این حال، کاربر قبلاً مجوز storage-access را اعطا کرده است، و واکشی شامل یک سرصفحه Sec-Fetch-Storage-Access: inactive که نشان می‌دهد دسترسی به کوکی پارتیشن نشده در دسترس است اما استفاده نمی‌شود.
سرور calendar.example با یک Activate-Storage-Access: retry; allowed-origin="<origin>" سرصفحه Activate-Storage-Access: retry; allowed-origin="<origin>" (در این مورد، <origin> https://website.example خواهد بود)، تا نشان دهد که واکشی منبع به استفاده از کوکی‌های پارتیشن نشده با مجوز دسترسی به ذخیره‌سازی نیاز دارد.
مرورگر درخواست را دوباره امتحان می کند، این بار شامل کوکی های بدون پارتیشن (فعال کردن مجوز storage-access برای این واکشی).
سرور calendar.example با محتوای شخصی‌شده iframe پاسخ می‌دهد. پاسخ شامل یک Activate-Storage-Access: load header است که نشان می دهد مرورگر باید محتوا را با مجوز storage-access فعال بارگیری کند (به عبارت دیگر، بارگیری با دسترسی به کوکی بدون پارتیشن، گویی که document.requestStorageAccess() فراخوانی شده است).
عامل کاربر محتوای iframe را با دسترسی به کوکی بدون پارتیشن با استفاده از مجوز دسترسی به ذخیره سازی بارگیری می کند. پس از این مرحله، ویجت می تواند همانطور که انتظار می رود کار کند.

فلوچارتی که جریان سربرگ دسترسی به ذخیره سازی را نشان می دهد — نمودار جریان هدر دسترسی به ذخیره سازی.

راه حل خود را به روز کنید

با ویژگی Storage Access Headers، ممکن است بخواهید کد خود را در دو مورد به روز کنید:

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

منطق سرصفحه های SAA را پیاده سازی کنید

برای استفاده از Storage Access Headers در راه حل خود، باید راه حل خود را به روز کنید. فرض کنید شما مالک calendar.example هستید. برای اینکه website.example بتواند یک ویجت شخصی شده calendar.example را بارگیری کند، کد ویجت باید به فضای ذخیره سازی دسترسی داشته باشد.

سمت مشتری

ویژگی Storage Access Headers برای راه حل های موجود نیازی به به روز رسانی کد در سمت مشتری ندارد. برای یادگیری نحوه اجرای SAA اسناد را بخوانید.

سمت سرور

در سمت سرور، می توانید از هدرهای جدید استفاده کنید:

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

  if (storageAccessHeader === 'inactive') {
    // User needs to grant permission, trigger a prompt
    if (!validate_origin(req.headers.origin)) {
      res.status(401).send(`${req.headers.origin} is not allowed to send` +
          ' credentialed requests to this server.');
      return;
    }
    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')
  }
});

نسخه ی نمایشی را بررسی کنید تا ببینید این راه حل در عمل چگونه کار می کند.

منطق سرصفحه Origin خود را به روز کنید

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

برای جلوگیری از مشکلات احتمالی، باید کد سمت سرور خود را بررسی کنید:

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

مزایای کلیدی

Storage Access Headers یک روش توصیه شده و کارآمدتر برای استفاده از SAA است. به طور کلی، این تغییر چندین پیشرفت را به همراه دارد:

پشتیبانی از جاسازی‌های غیرiframe: SAA را برای طیف وسیع‌تری از منابع فعال می‌کند.
کاهش استفاده از شبکه: درخواست های کمتر و بارهای کوچکتر.
استفاده کمتر از CPU: پردازش جاوا اسکریپت کمتر.
UX بهبود یافته: بارهای میانی مخل را حذف می کند.

در آزمایش مبدا شرکت کنید

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

می‌توانید با ثبت‌نام در نسخه‌های آزمایشی اصلی که از Chrome 130 شروع می‌شود، ویژگی Storage Access Headers را امتحان کنید. برای شرکت در نسخه آزمایشی اصلی:

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

به صورت محلی تست کنید

می توانید ویژگی Storage Access Headers را به صورت محلی آزمایش کنید تا مطمئن شوید که وب سایت شما برای این تغییر آماده است.

این مراحل را برای پیکربندی نمونه کروم خود دنبال کنید:

پرچم کروم را در chrome://flags/#storage-access-headers فعال کنید.
برای اعمال تغییرات، کروم را مجددا راه اندازی کنید.

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

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

Natalia Markoborodova

جریان جاوا اسکریپت (و محدودیت های آن)

رفت و برگشت چندگانه شبکه: این فرآیند اغلب شامل چندین درخواست شبکه و بارگیری مجدد صفحه قبل از اینکه محتوای تعبیه شده به طور کامل کار کند، می شود.
وابستگی به Iframe: اجرای جاوا اسکریپت استفاده از iframe یا منابع فرعی را در iframe الزامی می کند و انعطاف پذیری را برای توسعه دهندگان محدود می کند.

یک مکان نگهدار را بارگیری کنید: website.example ویجت را درخواست می کند. از آنجایی که ویجت calendar.example تعبیه شده در website.example به کوکی های پارتیشن نشده خود دسترسی ندارد، در عوض یک ویجت مکان نگهدار ارائه می شود.
درخواست مجوز: محل نگهدارنده بارگیری می شود، سپس document.requestStorageAccess() را برای درخواست مجوز storage-access فراخوانی می کند.
کاربر اعطای مجوز را انتخاب می کند .
ویجت را دوباره بارگذاری کنید: ویجت، این بار با دسترسی به کوکی، تازه می شود و در نهایت محتوای شخصی شده را بارگیری می کند.
هر بار که کاربر از سایتی بازدید می کند که ویجت calendar.example را دوباره جاسازی می کند، جریان دقیقاً مانند مراحل 1، 2 و 4 به نظر می رسد. تنها ساده سازی این است که کاربر نیازی به اعطای مجدد دسترسی ندارد.

جریان جدید با هدرهای HTTP

سربرگ درخواست

Sec-Fetch-Storage-Access: <access-status>

none : جاسازی مجوز storage-access را ندارد و بنابراین به کوکی های پارتیشن نشده دسترسی ندارد.
inactive : جاسازی دارای مجوز storage-access است، اما استفاده از آن را انتخاب نکرده است. جاسازی دسترسی به کوکی بدون پارتیشن ندارد.
active : جاسازی دسترسی به کوکی بدون پارتیشن دارد. این مقدار در درخواست‌های متقاطع که به کوکی‌های پارتیشن نشده دسترسی دارند، لحاظ می‌شود.

سرصفحه های پاسخ

Activate-Storage-Access: <retry-or-reload>

load : به مرورگر دستور می دهد تا به embedder اجازه دسترسی به کوکی های پارتیشن نشده برای منبع درخواستی بدهد.
retry : سرور پاسخ می دهد که مرورگر باید مجوز دسترسی به ذخیره سازی را فعال کند، سپس درخواست را دوباره امتحان کنید.

Activate-Storage-Access: retry; allowed-origin="https://site.example"
Activate-Storage-Access: retry; allowed-origin=*
Activate-Storage-Access: load

پشتیبانی از منابع غیر iframe

   <img src="https://server.example/image"/>

و سرور می تواند با محتوا یا خطا، بسته به اینکه یک کوکی در دسترس باشد، پاسخ دهد:

app.get('/image', (req, res) => {
  const headers = req.headers;
  const cookieHeader = headers.cookie;
  // Check if the embed has the necessary cookie access
  if (!cookieHeader || !cookieHeader.includes('foo')) {
  // If the cookie is not present, check if the browser supports Storage Access headers
    if (
      'sec-fetch-storage-access' in headers &&
      headers['sec-fetch-storage-access'] == 'inactive'
    ) {
    // If the browser supports Storage Access API, retry the request with storage access enabled
      res.setHeader('Activate-Storage-Access', 'retry; allowed-origin="https://embedding-site.example"');
    }
    res.status(401).send('No cookie!');
   } else {
    // If the cookie is available, check if the user is authorized to access the image
    if (!check_authorization(cookieHeader)) {
      return res.status(401).send('Unauthorized!');
    }
    // If the user is authorized, respond with the image file
    res.sendFile("path/to/image.jpeg");
  }
});

جریان سرصفحه HTTP

با سربرگ‌های دسترسی به فضای ذخیره‌سازی، بازدیدهای بعدی از صفحات جریان زیر را آغاز می‌کنند:

کاربر از website.example بازدید می کند که calendar.example دوباره جاسازی کرده است. این واکشی مانند قبل هنوز به کوکی دسترسی ندارد. با این حال، کاربر قبلاً مجوز storage-access را اعطا کرده است، و واکشی شامل یک سرصفحه Sec-Fetch-Storage-Access: inactive که نشان می‌دهد دسترسی به کوکی پارتیشن نشده در دسترس است اما استفاده نمی‌شود.
سرور calendar.example با یک Activate-Storage-Access: retry; allowed-origin="<origin>" سرصفحه Activate-Storage-Access: retry; allowed-origin="<origin>" (در این مورد، <origin> https://website.example خواهد بود)، تا نشان دهد که واکشی منبع به استفاده از کوکی‌های پارتیشن نشده با مجوز دسترسی به ذخیره‌سازی نیاز دارد.
مرورگر درخواست را دوباره امتحان می کند، این بار شامل کوکی های بدون پارتیشن (فعال کردن مجوز storage-access برای این واکشی).
سرور calendar.example با محتوای شخصی‌شده iframe پاسخ می‌دهد. پاسخ شامل یک Activate-Storage-Access: load header است که نشان می دهد مرورگر باید محتوا را با مجوز storage-access فعال بارگیری کند (به عبارت دیگر، بارگیری با دسترسی به کوکی بدون پارتیشن، گویی که document.requestStorageAccess() فراخوانی شده است).
عامل کاربر محتوای iframe را با دسترسی به کوکی بدون پارتیشن با استفاده از مجوز دسترسی به ذخیره سازی بارگیری می کند. پس از این مرحله، ویجت می تواند همانطور که انتظار می رود کار کند.

راه حل خود را به روز کنید

با ویژگی Storage Access Headers، ممکن است بخواهید کد خود را در دو مورد به روز کنید:

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

منطق سرصفحه های SAA را پیاده سازی کنید

سمت مشتری

سمت سرور

در سمت سرور، می توانید از هدرهای جدید استفاده کنید:

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

  if (storageAccessHeader === 'inactive') {
    // User needs to grant permission, trigger a prompt
    if (!validate_origin(req.headers.origin)) {
      res.status(401).send(`${req.headers.origin} is not allowed to send` +
          ' credentialed requests to this server.');
      return;
    }
    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')
  }
});

نسخه ی نمایشی را بررسی کنید تا ببینید این راه حل در عمل چگونه کار می کند.

منطق سرصفحه Origin خود را به روز کنید

برای جلوگیری از مشکلات احتمالی، باید کد سمت سرور خود را بررسی کنید:

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

مزایای کلیدی

پشتیبانی از جاسازی‌های غیرiframe: SAA را برای طیف وسیع‌تری از منابع فعال می‌کند.
کاهش استفاده از شبکه: درخواست های کمتر و بارهای کوچکتر.
استفاده کمتر از CPU: پردازش جاوا اسکریپت کمتر.
UX بهبود یافته: بارهای میانی مخل را حذف می کند.

در آزمایش مبدا شرکت کنید

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

به صورت محلی تست کنید

می توانید ویژگی Storage Access Headers را به صورت محلی آزمایش کنید تا مطمئن شوید که وب سایت شما برای این تغییر آماده است.

این مراحل را برای پیکربندی نمونه کروم خود دنبال کنید:

پرچم کروم را در chrome://flags/#storage-access-headers فعال کنید.
برای اعمال تغییرات، کروم را مجددا راه اندازی کنید.

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

Natalia Markoborodova

جریان جاوا اسکریپت (و محدودیت های آن)

رفت و برگشت چندگانه شبکه: این فرآیند اغلب شامل چندین درخواست شبکه و بارگیری مجدد صفحه قبل از اینکه محتوای تعبیه شده به طور کامل کار کند، می شود.
وابستگی به Iframe: اجرای جاوا اسکریپت استفاده از iframe یا منابع فرعی را در iframe الزامی می کند و انعطاف پذیری را برای توسعه دهندگان محدود می کند.

یک مکان نگهدار را بارگیری کنید: website.example ویجت را درخواست می کند. از آنجایی که ویجت calendar.example تعبیه شده در website.example به کوکی های پارتیشن نشده خود دسترسی ندارد، در عوض یک ویجت مکان نگهدار ارائه می شود.
درخواست مجوز: محل نگهدارنده بارگیری می شود، سپس document.requestStorageAccess() را برای درخواست مجوز storage-access فراخوانی می کند.
کاربر اعطای مجوز را انتخاب می کند .
ویجت را دوباره بارگذاری کنید: ویجت، این بار با دسترسی به کوکی، تازه می شود و در نهایت محتوای شخصی شده را بارگیری می کند.
هر بار که کاربر از سایتی بازدید می کند که ویجت calendar.example را دوباره جاسازی می کند، جریان دقیقاً مانند مراحل 1، 2 و 4 به نظر می رسد. تنها ساده سازی این است که کاربر نیازی به اعطای مجدد دسترسی ندارد.

جریان جدید با هدرهای HTTP

سربرگ درخواست

Sec-Fetch-Storage-Access: <access-status>

none : جاسازی مجوز storage-access را ندارد و بنابراین به کوکی های پارتیشن نشده دسترسی ندارد.
inactive : جاسازی دارای مجوز storage-access است، اما استفاده از آن را انتخاب نکرده است. جاسازی دسترسی به کوکی بدون پارتیشن ندارد.
active : جاسازی دسترسی به کوکی بدون پارتیشن دارد. این مقدار در درخواست‌های متقاطع که به کوکی‌های پارتیشن نشده دسترسی دارند، لحاظ می‌شود.

سرصفحه های پاسخ

Activate-Storage-Access: <retry-or-reload>

load : به مرورگر دستور می دهد تا به embedder اجازه دسترسی به کوکی های پارتیشن نشده برای منبع درخواستی بدهد.
retry : سرور پاسخ می دهد که مرورگر باید مجوز دسترسی به ذخیره سازی را فعال کند، سپس درخواست را دوباره امتحان کنید.

Activate-Storage-Access: retry; allowed-origin="https://site.example"
Activate-Storage-Access: retry; allowed-origin=*
Activate-Storage-Access: load

پشتیبانی از منابع غیر iframe

   <img src="https://server.example/image"/>

و سرور می تواند با محتوا یا خطا، بسته به اینکه یک کوکی در دسترس باشد، پاسخ دهد:

app.get('/image', (req, res) => {
  const headers = req.headers;
  const cookieHeader = headers.cookie;
  // Check if the embed has the necessary cookie access
  if (!cookieHeader || !cookieHeader.includes('foo')) {
  // If the cookie is not present, check if the browser supports Storage Access headers
    if (
      'sec-fetch-storage-access' in headers &&
      headers['sec-fetch-storage-access'] == 'inactive'
    ) {
    // If the browser supports Storage Access API, retry the request with storage access enabled
      res.setHeader('Activate-Storage-Access', 'retry; allowed-origin="https://embedding-site.example"');
    }
    res.status(401).send('No cookie!');
   } else {
    // If the cookie is available, check if the user is authorized to access the image
    if (!check_authorization(cookieHeader)) {
      return res.status(401).send('Unauthorized!');
    }
    // If the user is authorized, respond with the image file
    res.sendFile("path/to/image.jpeg");
  }
});

جریان سرصفحه HTTP

با سربرگ‌های دسترسی به فضای ذخیره‌سازی، بازدیدهای بعدی از صفحات جریان زیر را آغاز می‌کنند:

کاربر از website.example بازدید می کند که calendar.example دوباره جاسازی کرده است. این واکشی مانند قبل هنوز به کوکی دسترسی ندارد. با این حال، کاربر قبلاً مجوز storage-access را اعطا کرده است، و واکشی شامل یک سرصفحه Sec-Fetch-Storage-Access: inactive که نشان می‌دهد دسترسی به کوکی پارتیشن نشده در دسترس است اما استفاده نمی‌شود.
سرور calendar.example با یک Activate-Storage-Access: retry; allowed-origin="<origin>" سرصفحه Activate-Storage-Access: retry; allowed-origin="<origin>" (در این مورد، <origin> https://website.example خواهد بود)، تا نشان دهد که واکشی منبع به استفاده از کوکی‌های پارتیشن نشده با مجوز دسترسی به ذخیره‌سازی نیاز دارد.
مرورگر درخواست را دوباره امتحان می کند، این بار شامل کوکی های بدون پارتیشن (فعال کردن مجوز storage-access برای این واکشی).
سرور calendar.example با محتوای شخصی‌شده iframe پاسخ می‌دهد. پاسخ شامل یک Activate-Storage-Access: load header است که نشان می دهد مرورگر باید محتوا را با مجوز storage-access فعال بارگیری کند (به عبارت دیگر، بارگیری با دسترسی به کوکی بدون پارتیشن، گویی که document.requestStorageAccess() فراخوانی شده است).
عامل کاربر محتوای iframe را با دسترسی به کوکی بدون پارتیشن با استفاده از مجوز دسترسی به ذخیره سازی بارگیری می کند. پس از این مرحله، ویجت می تواند همانطور که انتظار می رود کار کند.

راه حل خود را به روز کنید

با ویژگی Storage Access Headers، ممکن است بخواهید کد خود را در دو مورد به روز کنید:

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

منطق سرصفحه های SAA را پیاده سازی کنید

سمت مشتری

سمت سرور

در سمت سرور، می توانید از هدرهای جدید استفاده کنید:

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

  if (storageAccessHeader === 'inactive') {
    // User needs to grant permission, trigger a prompt
    if (!validate_origin(req.headers.origin)) {
      res.status(401).send(`${req.headers.origin} is not allowed to send` +
          ' credentialed requests to this server.');
      return;
    }
    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')
  }
});

نسخه ی نمایشی را بررسی کنید تا ببینید این راه حل در عمل چگونه کار می کند.

منطق سرصفحه Origin خود را به روز کنید

برای جلوگیری از مشکلات احتمالی، باید کد سمت سرور خود را بررسی کنید:

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

مزایای کلیدی

پشتیبانی از جاسازی‌های غیرiframe: SAA را برای طیف وسیع‌تری از منابع فعال می‌کند.
کاهش استفاده از شبکه: درخواست های کمتر و بارهای کوچکتر.
استفاده کمتر از CPU: پردازش جاوا اسکریپت کمتر.
UX بهبود یافته: بارهای میانی مخل را حذف می کند.

در آزمایش مبدا شرکت کنید

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

به صورت محلی تست کنید

می توانید ویژگی Storage Access Headers را به صورت محلی آزمایش کنید تا مطمئن شوید که وب سایت شما برای این تغییر آماده است.

این مراحل را برای پیکربندی نمونه کروم خود دنبال کنید:

پرچم کروم را در chrome://flags/#storage-access-headers فعال کنید.
برای اعمال تغییرات، کروم را مجددا راه اندازی کنید.

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

Natalia Markoborodova

جریان جاوا اسکریپت (و محدودیت های آن)

رفت و برگشت چندگانه شبکه: این فرآیند اغلب شامل چندین درخواست شبکه و بارگیری مجدد صفحه قبل از اینکه محتوای تعبیه شده به طور کامل کار کند، می شود.
وابستگی به Iframe: اجرای جاوا اسکریپت استفاده از iframe یا منابع فرعی را در iframe الزامی می کند و انعطاف پذیری را برای توسعه دهندگان محدود می کند.

یک مکان نگهدار را بارگیری کنید: website.example ویجت را درخواست می کند. از آنجایی که ویجت calendar.example تعبیه شده در website.example به کوکی های پارتیشن نشده خود دسترسی ندارد، در عوض یک ویجت مکان نگهدار ارائه می شود.
درخواست مجوز: محل نگهدارنده بارگیری می شود، سپس document.requestStorageAccess() را برای درخواست مجوز storage-access فراخوانی می کند.
کاربر اعطای مجوز را انتخاب می کند .
ویجت را دوباره بارگذاری کنید: ویجت، این بار با دسترسی به کوکی، تازه می شود و در نهایت محتوای شخصی شده را بارگیری می کند.
هر بار که کاربر از سایتی بازدید می کند که ویجت calendar.example را دوباره جاسازی می کند، جریان دقیقاً مانند مراحل 1، 2 و 4 به نظر می رسد. تنها ساده سازی این است که کاربر نیازی به اعطای مجدد دسترسی ندارد.

جریان جدید با هدرهای HTTP

سربرگ درخواست

Sec-Fetch-Storage-Access: <access-status>

none : جاسازی شده اجازه storage-access را ندارد و بنابراین به کوکی های غیرقانونی دسترسی ندارد.
inactive : Embed دارای مجوز storage-access است ، اما تصمیم به استفاده از آن نگرفته است. جاسازی شده دسترسی به کوکی های غیرقابل تحمل ندارد.
active : Embed دارای دسترسی به کوکی های غیرقانونی است. این مقدار در هر درخواست متقاطع که به کوکی های غیرقابل تحمل دسترسی دارند ، گنجانده شده است.

سرصفحه های پاسخ

Activate-Storage-Access: <retry-or-reload>

هدر Activate-Storage-Access به مرورگر دستور می دهد که درخواست را با کوکی ها دوباره امتحان کند یا منبع را مستقیماً با SAA فعال شده بارگذاری کند. هدر می تواند مقادیر زیر را داشته باشد:

load : به مرورگر دستور می دهد تا دسترسی تعبیه شده به کوکی های غیرقانونی را برای منبع درخواست شده اعطا کند.
retry : سرور پاسخ می دهد که مرورگر باید اجازه دسترسی به ذخیره سازی را فعال کند ، سپس درخواست را دوباره امتحان کنید.

Activate-Storage-Access: retry; allowed-origin="https://site.example"
Activate-Storage-Access: retry; allowed-origin=*
Activate-Storage-Access: load

پشتیبانی از منابع غیر فریم

به روزرسانی هدر دسترسی به ذخیره سازی ، SAA را برای محتوای تعبیه شده غیر فریم ، مانند تصاویر میزبانی شده در یک دامنه متفاوت ، امکان پذیر می کند. پیش از این ، هیچ API پلتفرم وب در صورت عدم دسترسی به کوکی های شخص ثالث ، اجازه بارگیری چنین منابع با اعتبار در مرورگرها را نمی دهد. به عنوان مثال ، embedding-site.example شما می تواند یک تصویر را درخواست کند:

   <img src="https://server.example/image"/>

و سرور بسته به اینکه آیا یک کوکی در دسترس است ، می تواند با محتوا یا خطایی پاسخ دهد:

app.get('/image', (req, res) => {
  const headers = req.headers;
  const cookieHeader = headers.cookie;
  // Check if the embed has the necessary cookie access
  if (!cookieHeader || !cookieHeader.includes('foo')) {
  // If the cookie is not present, check if the browser supports Storage Access headers
    if (
      'sec-fetch-storage-access' in headers &&
      headers['sec-fetch-storage-access'] == 'inactive'
    ) {
    // If the browser supports Storage Access API, retry the request with storage access enabled
      res.setHeader('Activate-Storage-Access', 'retry; allowed-origin="https://embedding-site.example"');
    }
    res.status(401).send('No cookie!');
   } else {
    // If the cookie is available, check if the user is authorized to access the image
    if (!check_authorization(cookieHeader)) {
      return res.status(401).send('Unauthorized!');
    }
    // If the user is authorized, respond with the image file
    res.sendFile("path/to/image.jpeg");
  }
});

اگر کوکی در دسترس نباشد ، سرور مقدار عنوان درخواست Sec-Fetch-Storage-Access بررسی می کند. اگر این مقدار به صورت inactive تنظیم شود ، سرور با Activate-Storage-Access: retry ، نشان می دهد که درخواست باید با دسترسی به ذخیره سازی دوباره انجام شود. اگر کوکی وجود نداشته باشد و هدر Sec-Fetch-Storage-Access دارای مقدار غیرفعال نیست ، تصویر بارگیری نمی شود.

جریان هدر HTTP

با استفاده از هدرهای HTTP ، مرورگر می تواند تشخیص دهد که کاربر قبلاً مجوز دسترسی به ذخیره سازی را به ویجت اعطا کرده است و Iframe را با دسترسی به کوکی های غیرقانونی در طی بازدیدهای بعدی بارگیری می کند.

با سربرگ‌های دسترسی به فضای ذخیره‌سازی، بازدیدهای بعدی از صفحات جریان زیر را آغاز می‌کنند:

کاربر از website.example بازدید می کند. نمونه ای که دارای calendar.example است. نمونه دوباره تعبیه شده است. این واکشی مانند گذشته هنوز به کوکی دسترسی ندارد. با این حال ، کاربر قبلاً مجوز storage-access را اعطا کرده است ، و Fetch شامل یک Sec-Fetch-Storage-Access: inactive ، تا نشان دهد که دسترسی به کوکی های غیرقانونی در دسترس است اما در حال استفاده نیست.
سرور calendar.example با یک Activate-Storage-Access: retry; allowed-origin="<origin>" هدر Activate-Storage-Access: retry; allowed-origin="<origin>" (در این حالت ، <origin> https://website.example ) خواهد بود ، تا نشان دهد که واکشی منابع نیاز به استفاده از کوکی های غیرقابل تصرف با اجازه دسترسی به ذخیره سازی دارد.
این مرورگر درخواست را دوباره احیا می کند ، این بار از جمله کوکی های غیرقانونی (فعال کردن مجوز storage-access برای این واکشی).
سرور calendar.example با محتوای شخصی‌شده iframe پاسخ می‌دهد. این پاسخ شامل یک Activate-Storage-Access: load ، برای نشان دادن اینکه مرورگر باید محتوا را با مجوز storage-access فعال شده بارگیری کند (به عبارت دیگر ، با دسترسی به کوکی های غیرقانونی بارگذاری شده ، گویی document.requestStorageAccess() فراخوانی شده است).
عامل کاربر محتوای iframe را با دسترسی به کوکی بدون پارتیشن با استفاده از مجوز دسترسی به ذخیره سازی بارگیری می کند. پس از این مرحله، ویجت می تواند همانطور که انتظار می رود کار کند.

راه حل خود را به روز کنید

با ویژگی Headers Access Access ، ممکن است بخواهید کد خود را در دو مورد به روز کنید:

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

منطق هدر SAA را پیاده سازی کنید

برای استفاده از هدرهای دسترسی به ذخیره سازی در راه حل خود ، باید راه حل خود را به روز کنید. فرض کنید شما صاحب calendar.example هستید. برای website.example نمونه برای بارگیری calendar.example شخصی. مثال ، کد ویجت باید دسترسی به ذخیره سازی داشته باشد.

سمت مشتری

ویژگی Headers Access Access نیازی به بروزرسانی کد در سمت مشتری برای راه حل های موجود ندارد. برای یادگیری نحوه اجرای SAA ، مستندات را بخوانید.

سمت سرور

در سمت سرور می توانید از هدر جدید استفاده کنید:

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

  if (storageAccessHeader === 'inactive') {
    // User needs to grant permission, trigger a prompt
    if (!validate_origin(req.headers.origin)) {
      res.status(401).send(`${req.headers.origin} is not allowed to send` +
          ' credentialed requests to this server.');
      return;
    }
    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')
  }
});

نسخه ی نمایشی را بررسی کنید تا ببینید که چگونه این راه حل در عمل کار می کند.

منطق هدر مبدا خود را به روز کنید

با استفاده از هدر دسترسی به ذخیره سازی ، Chrome عنوان Origin را در درخواست های بیشتر از گذشته ارسال می کند. این امر می تواند بر منطق طرف سرور شما تأثیر بگذارد اگر فقط به عنوان مبداء متکی باشد که فقط برای انواع خاصی از درخواست ها وجود دارد (مانند مواردی که توسط COR ها تعریف شده است).

برای جلوگیری از مشکلات احتمالی ، باید کد سمت سرور خود را مرور کنید:

هرگونه اعتبار سنجی یا منطقی را که بستگی به حضور عنوان Origin دارد ، بررسی کنید.
کد خود را به روز کنید تا هدر Origin موجود در موارد بیشتر باشد.

مزایای کلیدی

هدرهای دسترسی به ذخیره سازی یک روش توصیه شده و عملکردی تر برای استفاده از SAA است. به طور کلی ، این تغییر چندین پیشرفت را به همراه دارد:

پشتیبانی از تعبیه غیر IFRAME: SAA را برای طیف گسترده تری از منابع قادر می سازد.
کاهش استفاده از شبکه: درخواست های کمتری و بارهای کوچکتر.
استفاده از CPU پایین: پردازش JavaScript کمتر.
بهبود UX: بارهای میانی مختل کننده را از بین می برد.

در دادگاه مبدا شرکت کنید

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

با ثبت نام در آزمایشات مبدأ شروع از Chrome 130 می توانید ویژگی Headers Access Storage را امتحان کنید. برای شرکت در آزمایش مبدا:

به صفحه ثبت نام آزمایشی مبدأی Origin Seamers Origin بروید.
دستورالعمل های مربوط به مشارکت آزمایشی را دنبال کنید.

به صورت محلی تست کنید

برای اطمینان از آماده شدن وب سایت شما برای این تغییر ، می توانید ویژگی Headers Access را به صورت محلی آزمایش کنید.

برای پیکربندی نمونه Chrome خود این مراحل را دنبال کنید:

پرچم Chrome را روی chrome://flags/#storage-access-headers .
Chrome را مجدداً راه اندازی کنید تا تغییرات عملی شود.

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

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