إصدار تجريبي من Origin يتيح استخدام رؤوس HTTP في ميزة "الوصول إلى مساحة التخزين"

Natalia Markoborodova

سيبدأ Chrome مرحلة تجربة وتقييم لإضافة عناوين HTTP إلى واجهة برمجة التطبيقات Storage Access API (SAA) في الإصدار 130: عناوين الوصول إلى مساحة التخزين. يهدف عنوان الطلب Sec-Fetch-Storage-Access وعنوان الاستجابة Activate-Storage-Access الجديدان إلى إتاحة استخدام الموارد غير المستندة إلى إطار iframe، وتحسين الأداء وتجربة المستخدم للمواقع الإلكترونية التي تعتمد على المحتوى المضمّن، مثل التطبيقات المصغّرة للوسائط الاجتماعية والتقاويم والأدوات التفاعلية.

مسار JavaScript (وقيوده)

في السابق، كان يجب إجراء طلب بيانات من JavaScript API إلى document.requestStorageAccess() عند كل عملية إعادة تحميل، حتى إذا سبق للمستخدم منح الإذن. على الرغم من فعالية هذه الطريقة، إلا أنّها تفرض بعض القيود:

• عمليات تبادل بيانات متعددة عبر الشبكة: غالبًا ما كانت العملية تتضمن العديد من طلبات الشبكة وعمليات إعادة تحميل الصفحة قبل أن يتمكّن المحتوى المضمّن من العمل بشكل كامل.
• الاعتماد على إطارات iframe: كان تنفيذ JavaScript يفرض استخدام إطارات iframe أو موارد فرعية داخل إطارات iframe، ما يحدّ من مرونة المطوّرين.

على سبيل المثال، إذا تم تضمين تطبيق مصغّر للتقويم من calendar.example في website.example باستخدام JavaScript فقط، سيظهر على النحو التالي:

1. تحميل عنصر نائب: يطلب website.example الأداة. بما أنّ التطبيق المصغّر calendar.example المضمّن في website.example لا يمكنه الوصول إلى ملفات تعريف الارتباط غير المقسّمة، يتم عرض تطبيق مصغّر عنصر نائب بدلاً من ذلك.
2. طلب الإذن: يتم تحميل العنصر النائب، ثم يتم استدعاء document.requestStorageAccess() لطلب إذن storage-access.
3. يختار المستخدم منح الإذن.
4. إعادة تحميل التطبيق المصغّر: يتم تحديث التطبيق المصغّر هذه المرة مع إمكانية الوصول إلى ملفات تعريف الارتباط، وفي النهاية يتم تحميل المحتوى المخصّص.
5. في كل مرة يزور فيها المستخدم موقعًا إلكترونيًا يحتوي على تطبيق مصغّر calendar.example، يكون الإجراء متطابقًا تمامًا مع الخطوات 1 و2 و4، مع الاختلاف الوحيد أنّ المستخدم لن يحتاج إلى منح الإذن بالوصول مرة أخرى.

هذه العملية غير فعّالة: إذا سبق للمستخدم منح إذن التخزين، يصبح تحميل iframe الأولي وطلب document.requestStorageAccess() وإعادة التحميل اللاحقة غير ضروريَين، ما يؤدي إلى حدوث تأخير.

الخطوات الجديدة باستخدام عناوين HTTP

تتيح رؤوس الوصول إلى مساحة التخزين الجديدة تحميل المحتوى المضمّن بكفاءة أكبر، بما في ذلك الموارد غير المستندة إلى إطار iframe.

باستخدام عناوين الوصول إلى مساحة التخزين، سيجلب المتصفّح تلقائيًا الموارد التي تم ضبط عنوان الطلب Sec-Fetch-Storage-Access: inactive عليها إذا سبق للمستخدم منح الإذن. ولا يحتاج المطوّر إلى اتّخاذ أي إجراء لضبط عنوان الطلب. يمكن للخادم الردّ باستخدام العنوان Activate-Storage-Access: retry; allowed-origin="<origin>"، وسيعيد المتصفّح محاولة إرسال الطلب باستخدام بيانات الاعتماد اللازمة.

ملاحظة مهمة: لا يؤدي هذا التعديل إلى تغيير عملية طلب الأذونات الأولية. لا تزال المواقع الإلكترونية بحاجة إلى تضمين إطار iframe يستدعي document.requestStorageAccess() لطلب إذن المستخدم في حال عدم منحه بعد.

عنوان الطلب

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: يوجّه المتصفّح إلى منح القائم بالضمين إذن الوصول إلى ملفات تعريف الارتباط غير المقسّمة للمورد المطلوب.
• retry: يردّ الخادم بأنّه على المتصفّح تفعيل إذن الوصول إلى مساحة التخزين، ثم إعادة محاولة إرسال الطلب.

ملاحظة مهمة: عند استخدام retry، يجب أن يتضمّن ردّك أيضًا المَعلمة allowed-origin لمنح إذن مصدر لإرسال طلبات مستندة إلى بيانات اعتماد إلى خادمك. بالإضافة إلى ذلك، يجب أن يكون الطلب الأولي قد تضمّن العنوان Sec-Fetch-Storage-Access: inactive.

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

دعم المصادر غير المستندة إلى إطارات iframe

يتيح تعديل "رؤوس الوصول إلى مساحة التخزين" إمكانية الوصول إلى مساحة التخزين للمحتوى المضمّن غير المستند إلى إطار iframe، مثل الصور المستضافة على نطاق مختلف. في السابق، لم تسمح أي واجهة برمجة تطبيقات لمنصّة الويب بتحميل هذه الموارد باستخدام بيانات الاعتماد في المتصفّحات في حال عدم توفّر ملفات تعريف الارتباط التابعة لجهات خارجية. على سبيل المثال، يمكن لتطبيق 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 القيمة غير نشط، لن يتم تحميل الصورة.

ملاحظة: يمكنك استخدام العنوان Activate-Storage-Access: retry لموارد غير إطار iframe بدون استخدام Activate-Storage-Access: load لاحقًا. إنّ عنوان الاستجابة load مخصّص لإطارات iframe، وهو يعادل تنفيذ await document.requestStorageAccess() وإعادة تحميل النافذة. باستخدام عنوان الاستجابة load، يتم جلب إطار iframe وتحميله مرة واحدة فقط.

تدفّق عناوين 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 من خلال الوصول إلى ملف تعريف ارتباط غير مقسَّم باستخدام إذن الوصول إلى مساحة التخزين. بعد هذه الخطوة، يمكن أن يعمل التطبيق المصغّر على النحو المتوقّع.

مخطّط تدفق عنوان "الوصول إلى مساحة التخزين"

تعديل الحلّ

باستخدام ميزة "رؤوس الوصول إلى مساحة التخزين"، قد تحتاج إلى تعديل الرمز في حالتَين:

1. إذا كنت تستخدِم نموذج SAA وتريد تحقيق أداء أفضل باستخدام منطق العنوان
2. لديك عملية تحقّق أو منطق يعتمد على ما إذا كان عنوان Origin مضمّنًا في الطلب على خادمك.

تنفيذ منطق عناوين SAA

لاستخدام رؤوس الوصول إلى مساحة التخزين في الحلّ، عليك تعديل الحلّ. لنفترض أنّك مالك calendar.example. لكي تتمكّن من تحميل تطبيق مصغّر مخصّص على website.example، يجب أن يكون لرمز التطبيق المصغّر إذن الوصول إلى مساحة التخزين.calendar.example

من جهة العميل

لا تتطلّب ميزة "رؤوس الوصول إلى مساحة التخزين" أي تعديل على الرمز من جهة العميل للحلول الحالية. اطّلِع على المستندات لمعرفة كيفية تنفيذ 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 في المزيد من الحالات.

المزايا الرئيسية

وتعدّ "رؤوس الوصول إلى مساحة التخزين" طريقة مُقترَحة وأكثر فعالية لاستخدام "الوصول الآمن إلى البيانات". بشكل عام، يقدّم هذا التغيير العديد من التحسينات:

• إتاحة عمليات التضمين التي لا تستخدم إطار iframe: تتيح هذه الميزة استخدام ميزة SAA مع مجموعة أكبر من المراجع.
• استخدام أقل للشبكة: عدد طلبات أقل وحمولات أصغر
• استخدام وحدة المعالجة المركزية بدرجة أقل: تقليل معالجة JavaScript
• تجربة مستخدم محسّنة: تُلغي عمليات التحميل المؤقتة المزعجة.

المشاركة في الفترة التجريبية لإصدار التطبيق الأصلي

تتيح لك مراحل التجربة والتقييم تجربة ميزات جديدة وتقديم ملاحظات حول سهولة استخدامها وفعاليتها ومدى ملاءمتها للتطبيق. لمزيد من المعلومات، اطّلِع على مقالة البدء في استخدام تجارب المصدر.

يمكنك تجربة ميزة "رؤوس الوصول إلى مساحة التخزين" من خلال التسجيل في إصدارات الإصدارات التجريبية من Chrome 130 والإصدارات الأحدث. للمشاركة في الفترة التجريبية الأصلية:

1. انتقِل إلى صفحة التسجيل لتجربة استخدام ميزة "رؤوس الوصول إلى مساحة التخزين".
2. اتّبِع التعليمات المتعلّقة بالمشاركة في الفترة التجريبية الأصلية.

الاختبار على الجهاز

يمكنك اختبار ميزة "رؤوس الوصول إلى مساحة التخزين" على الجهاز فقط للتأكّد من استعداد موقعك الإلكتروني لهذا التغيير.

اتّبِع الخطوات التالية لضبط مثيل Chrome:

1. فعِّل الميزة التجريبية في Chrome على chrome://flags/#storage-access-headers.
2. أعِد تشغيل Chrome لتصبح التغييرات سارية.

التفاعل مع الملاحظات ومشاركتها

إذا كانت لديك ملاحظات أو واجهت أي مشاكل، يمكنك الإبلاغ عن مشكلة. يمكنك أيضًا الاطّلاع على مزيد من المعلومات حول رؤوس الوصول إلى مساحة التخزين في الشرح على GitHub.