स्टोरेज ऐक्सेस में एचटीटीपी हेडर की सुविधा के लिए ऑरिजिन ट्रायल

Natalia Markoborodova

Chrome, 130 वर्शन में Storage Access API (SAA) में एचटीटीपी हेडर जोड़ने के लिए, ऑरिजिन ट्रायल शुरू कर रहा है: Storage Access Headers. नए Sec-Fetch-Storage-Access अनुरोध हेडर और Activate-Storage-Access जवाब हेडर का मकसद, नॉन-आईफ़्रेम संसाधनों के साथ काम करना है. साथ ही, एम्बेड किए गए कॉन्टेंट पर निर्भर रहने वाली वेबसाइटों की परफ़ॉर्मेंस और उपयोगकर्ता अनुभव को बेहतर बनाना है. जैसे, सोशल मीडिया विजेट, कैलेंडर, और इंटरैक्टिव टूल.

JavaScript फ़्लो (और इसकी सीमाएं)

इससे पहले, SAA को हर बार रीलोड करने पर document.requestStorageAccess() के लिए JavaScript API कॉल की ज़रूरत होती थी. भले ही, उपयोगकर्ता ने पहले ही अनुमति दे दी हो. यह तरीका असरदार है, लेकिन इसमें कुछ सीमाएं हैं:

  • नेटवर्क के कई राउंड ट्रिप: इस प्रोसेस में, एम्बेड किए गए कॉन्टेंट के पूरी तरह से काम करने से पहले, अक्सर कई नेटवर्क अनुरोध और पेज रीलोड शामिल होते थे.
  • आईफ़्रेम पर निर्भरता: JavaScript को चलाने के लिए, आईफ़्रेम या आईफ़्रेम में मौजूद सब-रिसोर्स का इस्तेमाल करना ज़रूरी था. इससे डेवलपर को काम करने में मुश्किल होती थी.

उदाहरण के लिए, सिर्फ़ JavaScript का इस्तेमाल करके, website.example पर एम्बेड किया गया calendar.example का कैलेंडर विजेट ऐसा दिखेगा:

  1. प्लेसहोल्डर लोड करना: website.example विजेट का अनुरोध करता है. website.example पर एम्बेड किए गए calendar.example विजेट के पास, बिना बंटवारे वाली कुकी का ऐक्सेस नहीं है. इसलिए, प्लेसहोल्डर विजेट रेंडर किया जाता है.
  2. अनुमति का अनुरोध करें: प्लेसहोल्डर लोड होता है. इसके बाद, storage-access की अनुमति का अनुरोध करने के लिए, document.requestStorageAccess() को कॉल करता है.
  3. उपयोगकर्ता अनुमति देने का विकल्प चुनता है.
  4. विजेट को फिर से लोड करें: इससे विजेट रीफ़्रेश हो जाता है. इस बार, कुकी को ऐक्सेस करने की अनुमति मिल जाती है. इसके बाद, आपकी दिलचस्पी के हिसाब से कॉन्टेंट लोड हो जाता है.
  5. जब उपयोगकर्ता, calendar.example विजेट को एम्बेड करने वाली किसी साइट पर दोबारा जाता है, तो फ़्लो बिलकुल वैसा ही होता है जैसा कि 1, 2, और 4 चरणों में बताया गया है. इसमें सिर्फ़ यह बदलाव होता है कि उपयोगकर्ता को फिर से ऐक्सेस देने की ज़रूरत नहीं होती.

यह फ़्लो सही नहीं है: अगर उपयोगकर्ता ने पहले ही स्टोरेज की अनुमति दे दी है, तो शुरुआती iframe लोड, document.requestStorageAccess() कॉल, और बाद में फिर से लोड करने की ज़रूरत नहीं होती. इससे लेटेन्सी बढ़ती है.

एचटीटीपी हेडर के साथ नया फ़्लो

नए Storage Access Headers की मदद से, एम्बेड किए गए कॉन्टेंट को ज़्यादा असरदार तरीके से लोड किया जा सकता है. इसमें 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 हेडर, ब्राउज़र को यह निर्देश देता है कि वह कुकी के साथ अनुरोध को फिर से आज़माए या एसएए चालू करके सीधे तौर पर संसाधन लोड करे. हेडर में ये वैल्यू हो सकती हैं:

  • load: यह ब्राउज़र को निर्देश देता है कि वह अनुरोध किए गए संसाधन के लिए, एम्बेड करने वाले को बिना बंटे हुए कुकी का ऐक्सेस दे.
  • retry: सर्वर यह जवाब देता है कि ब्राउज़र को स्टोरेज ऐक्सेस करने की अनुमति चालू करनी चाहिए. इसके बाद, अनुरोध को फिर से आज़माना चाहिए.
Activate-Storage-Access: retry; allowed-origin="https://site.example"
Activate-Storage-Access: retry; allowed-origin=*
Activate-Storage-Access: load

नॉन-आईफ़्रेम रिसॉर्स के लिए सहायता

Storage Access Headers अपडेट की मदद से, iframe के अलावा एम्बेड किए गए कॉन्टेंट के लिए SAA को चालू किया जा सकता है. जैसे, किसी दूसरे डोमेन पर होस्ट की गई इमेज. इससे पहले, कोई भी वेब प्लैटफ़ॉर्म एपीआई, ब्राउज़र में क्रेडेंशियल के साथ ऐसे संसाधनों को लोड करने की अनुमति नहीं देता था. ऐसा तब होता था, जब तीसरे पक्ष की कुकी उपलब्ध नहीं होती थीं. उदाहरण के लिए, आपका 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 पर सेट किया जाता है, तो सर्वर inactive हेडर के साथ जवाब देता है. इससे पता चलता है कि स्टोरेज ऐक्सेस के साथ अनुरोध को फिर से आज़माया जाना चाहिए.Activate-Storage-Access: retry अगर कोई कुकी मौजूद नहीं है और Sec-Fetch-Storage-Access हेडर में inactive वैल्यू नहीं है, तो इमेज लोड नहीं होगी.

एचटीटीपी हेडर का फ़्लो

एचटीटीपी हेडर की मदद से, ब्राउज़र यह पहचान सकता है कि उपयोगकर्ता ने विजेट को स्टोरेज ऐक्सेस करने की अनुमति पहले ही दे दी है. साथ ही, बाद की विज़िट के दौरान, ब्राउज़र ऐसे 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 Header के फ़्लो के बारे में बताया गया है.
Storage Access API के हेडर का फ़्लो डायग्राम.

अपने समाधान को अपडेट करना

Storage Access Headers सुविधा का इस्तेमाल करते समय, आपको इन दो मामलों में अपना कोड अपडेट करना पड़ सकता है:

  1. एसएए का इस्तेमाल किया जाता है और हेडर लॉजिक की मदद से बेहतर परफ़ॉर्मेंस हासिल करनी है.
  2. आपके पास ऐसा लॉजिक या पुष्टि करने का तरीका है जो इस बात पर निर्भर करता है कि आपके सर्वर पर अनुरोध में Origin हेडर शामिल है या नहीं.

एसएए हेडर लॉजिक लागू करना

अपने समाधान में Storage Access Headers का इस्तेमाल करने के लिए, आपको अपने समाधान को अपडेट करना होगा. मान लें कि आप calendar.example के मालिक हैं. website.example को आपकी पसंद के मुताबिक calendar.example विजेट लोड करने के लिए, विजेट कोड के पास स्टोरेज का ऐक्सेस होना चाहिए.

क्लाइंट साइड

स्टोरेज ऐक्सेस हेडर की सुविधा के लिए, क्लाइंट-साइड पर मौजूदा समाधानों के लिए किसी कोड अपडेट की ज़रूरत नहीं होती. एसएए लागू करने का तरीका जानने के लिए, दस्तावेज़ पढ़ें.

सर्वर साइड

सर्वर साइड पर, इन नए हेडर का इस्तेमाल किया जा सकता है:

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 हेडर भेजता है. अगर आपका सर्वर-साइड लॉजिक, सिर्फ़ कुछ खास तरह के अनुरोधों (जैसे, सीओआरएस के ज़रिए तय किए गए अनुरोध) के लिए Origin हेडर के मौजूद होने पर निर्भर करता है, तो इससे उस पर असर पड़ सकता है.

संभावित समस्याओं से बचने के लिए, आपको अपने सर्वर-साइड कोड की समीक्षा करनी होगी:

  • देखें कि क्या कोई पुष्टि या लॉजिक, Origin हेडर की मौजूदगी पर निर्भर करता है.
  • ज़्यादा मामलों में Origin हेडर मौजूद होने पर, उसे हैंडल करने के लिए अपना कोड अपडेट करें.

मुख्य फ़ायदे

SAA का इस्तेमाल करने के लिए, Storage Access Headers का सुझाव दिया जाता है. इससे बेहतर परफ़ॉर्मेंस मिलती है. कुल मिलाकर, इस बदलाव से कई सुधार हुए हैं:

  • नॉन-आईफ़्रेम एम्बेड करने की सुविधा: इससे ज़्यादा संसाधनों के लिए SAA को चालू किया जा सकता है.
  • नेटवर्क का कम इस्तेमाल: कम अनुरोध और छोटे पेलोड.
  • सीपीयू का कम इस्तेमाल: JavaScript प्रोसेसिंग कम होती है.
  • बेहतर यूज़र एक्सपीरियंस: इससे बीच में आने वाले रुकावटों को दूर किया जा सकता है.

ऑरिजिन ट्रायल में हिस्सा लेना

ऑरिजिन ट्रायल से, नई सुविधाओं को आज़माया जा सकता है. साथ ही, उनके इस्तेमाल में आसानी, व्यावहारिक होने, और असरदार होने के बारे में सुझाव/राय दी जा सकती है या शिकायत की जा सकती है. ज़्यादा जानकारी के लिए, ऑरिजिन ट्रायल का इस्तेमाल शुरू करना लेख पढ़ें.

Chrome 130 से शुरू होने वाली ओरिजिन ट्रायल के लिए रजिस्टर करके, Storage Access Headers सुविधा को आज़माया जा सकता है. ऑरिजिन ट्रायल में हिस्सा लेने के लिए:

  1. Storage Access Headers की ऑरिजिन ट्रायल के रजिस्ट्रेशन पेज पर जाएं.
  2. ओरिजिन ट्रायल में हिस्सा लेने के लिए, निर्देशों का पालन करें.

लोकल तौर पर टेस्ट करना

Storage Access Headers सुविधा को स्थानीय तौर पर टेस्ट किया जा सकता है. इससे यह पक्का किया जा सकता है कि आपकी वेबसाइट इस बदलाव के लिए तैयार है.

अपने Chrome इंस्टेंस को कॉन्फ़िगर करने के लिए, यह तरीका अपनाएं:

  1. chrome://flags/#storage-access-headers पर Chrome फ़्लैग चालू करें.
  2. बदलावों को लागू करने के लिए, Chrome को रीस्टार्ट करें.

उपयोग करना और सुझाव/राय देना या शिकायत करना

अगर आपको कोई सुझाव देना है या कोई समस्या आ रही है, तो समस्या की शिकायत दर्ज करें. GitHub के बारे में जानकारी देने वाले लेख में, स्टोरेज ऐक्सेस हेडर के बारे में ज़्यादा जानकारी भी देखी जा सकती है.