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

Natalia Markoborodova

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

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

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

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

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

1. بارگذاری یک placeholder: website.example ویجت را درخواست می‌کند. از آنجایی که ویجت calendar.example که در website.example تعبیه شده است به کوکی‌های پارتیشن‌بندی نشده خود دسترسی ندارد، به جای آن یک ویجت placeholder رندر می‌شود.
2. درخواست مجوز: متغیر placeholder بارگذاری می‌شود، سپس document.requestStorageAccess() را برای درخواست مجوز storage-access فراخوانی می‌کند.
3. کاربر تصمیم می‌گیرد که مجوز بدهد.
4. ویجت را دوباره بارگذاری کنید: ویجت، این بار با دسترسی به کوکی‌ها، به‌روزرسانی می‌شود و در نهایت محتوای شخصی‌سازی‌شده را بارگذاری می‌کند.
5. هر بار که کاربر دوباره از سایتی که ویجت calendar.example را در خود جای داده است بازدید می‌کند، روند کار دقیقاً مشابه مراحل ۱، ۲ و ۴ است؛ تنها نکته ساده‌سازی این است که کاربر نیازی به اعطای مجدد دسترسی ندارد.

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

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

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

با استفاده از هدرهای دسترسی به حافظه، مرورگر به طور خودکار منابع را با هدر درخواست Sec-Fetch-Storage-Access: inactive دریافت می‌کند، البته اگر کاربر قبلاً مجوز را اعطا کرده باشد. برای تنظیم هدر درخواست، نیازی به اقدام توسعه‌دهنده نیست. سرور می‌تواند با هدر 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

به‌روزرسانی Storage Access Headers، 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 مقدار inactive را نداشته باشد، تصویر بارگذاری نمی‌شود.

جریان هدر HTTP

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

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

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

راهکار خود را به‌روزرسانی کنید

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

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

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

برای استفاده از هدرهای دسترسی به فضای ذخیره‌سازی در راهکار خود، باید راهکار خود را به‌روزرسانی کنید. فرض کنید شما مالک 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 خود را به‌روزرسانی کنید

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

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

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

مزایای کلیدی

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

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

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

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

می‌توانید با ثبت‌نام در نسخه‌های آزمایشی اصلی (original trial) از کروم ۱۳۰، ویژگی Storage Access Headers را امتحان کنید. برای شرکت در نسخه آزمایشی اصلی:

1. به صفحه ثبت نام آزمایشی نسخه اصلی Storage Access Headers بروید.
2. دستورالعمل‌های مربوط به شرکت در آزمایش مبدا را دنبال کنید.

تست به صورت محلی

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

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

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

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

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