Storage Access API

ब्राउज़र, उपयोगकर्ता की सेटिंग, और स्टोरेज पार्टिशनिंग की मदद से तीसरे पक्ष की कुकी को ब्लॉक करने की सुविधा उपलब्ध कराते हैं. इससे उन साइटों और सेवाओं को मुश्किलों का सामना करना पड़ता है जो एम्बेड किए गए कॉन्टेक्स्ट में कुकी और अन्य स्टोरेज पर निर्भर करती हैं. जैसे, पुष्टि करने जैसी उपयोगकर्ता की यात्राओं के लिए. Storage Access API (SAA) की मदद से, इन इस्तेमाल के उदाहरणों को जारी रखा जा सकता है. साथ ही, अलग-अलग साइटों पर की जाने वाली ट्रैकिंग को ज़्यादा से ज़्यादा सीमित किया जा सकता है.

लागू करने की स्थिति

Storage Access API, सभी मुख्य ब्राउज़र में उपलब्ध है. हालांकि, ब्राउज़र के हिसाब से, इसे लागू करने के तरीके में थोड़ा अंतर है. इन अंतरों को इस पोस्ट के संबंधित सेक्शन में हाइलाइट किया गया है.

एपीआई को स्टैंडर्ड बनाने से पहले, ब्लॉक करने से जुड़ी सभी बाकी समस्याओं को हल करने का काम जारी है.

Storage Access API क्या है?

Storage Access API एक JavaScript API है. यह iframe को तब स्टोरेज ऐक्सेस करने की अनुमति का अनुरोध करने की सुविधा देता है, जब इस अनुरोध को ब्राउज़र सेटिंग खारिज कर देती हैं. जिन एम्बेड के इस्तेमाल के उदाहरण, क्रॉस-साइट संसाधनों को लोड करने पर निर्भर करते हैं वे इस एपीआई का इस्तेमाल करके, उपयोगकर्ता से ऐक्सेस करने की अनुमति मांग सकते हैं. ऐसा सिर्फ़ तब किया जा सकता है, जब इसकी ज़रूरत हो.

अगर स्टोरेज का अनुरोध स्वीकार कर लिया जाता है, तो iframe को बिना सेक्शन वाली कुकी और स्टोरेज का ऐक्सेस मिल जाएगा. ये कुकी और स्टोरेज तब भी उपलब्ध होते हैं, जब उपयोगकर्ता इसे टॉप-लेवल साइट के तौर पर विज़िट करते हैं.

Storage Access API की मदद से, बिना बंटी हुई कुकी और स्टोरेज का ऐक्सेस दिया जा सकता है. इससे असली उपयोगकर्ता पर कम असर पड़ता है. साथ ही, बिना बंटी हुई सामान्य कुकी और स्टोरेज का ऐक्सेस रोका जा सकता है. इसका इस्तेमाल अक्सर उपयोगकर्ता को ट्रैक करने के लिए किया जाता है.

उपयोग के उदाहरण

तीसरे पक्ष के कुछ एम्बेड को, बिना बांटी गई कुकी या स्टोरेज का ऐक्सेस चाहिए होता है, ताकि उपयोगकर्ता को बेहतर अनुभव दिया जा सके. हालांकि, तीसरे पक्ष की कुकी पर पाबंदी लगने और स्टोरेज पार्टिशनिंग चालू होने पर, ऐसा नहीं किया जा सकेगा.

इस्तेमाल के उदाहरणों में ये शामिल हैं:

• एम्बेड किए गए ऐसे कमेंट विजेट जिनमें लॉगिन सेशन की जानकारी ज़रूरी होती है.
• सोशल मीडिया पर मौजूद "पसंद करें" बटन. इनके लिए, लॉगिन सेशन की जानकारी ज़रूरी होती है.
• एम्बेड किए गए ऐसे दस्तावेज़ जिनके लिए लॉगिन सेशन की जानकारी ज़रूरी होती है.
• वीडियो एम्बेड करने के लिए, प्रीमियम अनुभव उपलब्ध कराया जाता है. उदाहरण के लिए, लॉग इन किए हुए उपयोगकर्ताओं को विज्ञापन न दिखाना या बंद कैप्शन के लिए उपयोगकर्ता की प्राथमिकताओं के बारे में जानना या कुछ वीडियो टाइप पर पाबंदी लगाना.
• एम्बेड किए गए पेमेंट सिस्टम.

इनमें से कई मामलों में, एम्बेड किए गए iframe में लॉगिन ऐक्सेस बनाए रखना शामिल है.

अन्य एपीआई के बजाय, Storage Access API का इस्तेमाल कब करना चाहिए

Storage Access API, बिना बंटे हुए कुकी और स्टोरेज का इस्तेमाल करने के विकल्पों में से एक है. इसलिए, यह समझना ज़रूरी है कि अन्य एपीआई की तुलना में इस एपीआई का इस्तेमाल कब करना चाहिए. इसका इस्तेमाल उन मामलों में किया जाता है जहां ये दोनों बातें सही हों:

• उपयोगकर्ता, एम्बेड किए गए कॉन्टेंट से इंटरैक्ट करेगा. इसका मतलब है कि यह पैसिव iframe या छिपा हुआ iframe नहीं है.
• उपयोगकर्ता ने टॉप-लेवल कॉन्टेक्स्ट में एम्बेड किए गए ऑरिजिन पर विज़िट किया हो. इसका मतलब है कि जब वह ऑरिजिन किसी दूसरी साइट में एम्बेड न किया गया हो.

इस्तेमाल के कई उदाहरणों के लिए, अन्य एपीआई उपलब्ध हैं:

• कुकीज़ हैविंग इंडिपेंडेंट पार्टिशन्ड स्टेट (सीएचआईपीएस) की मदद से डेवलपर, कुकी को "पार्टिशन किए गए" स्टोरेज में ऑप्ट-इन कर सकते हैं. इसमें हर टॉप-लेवल साइट के लिए अलग कुकी जार होता है. उदाहरण के लिए, तीसरे पक्ष का वेब-चैट विजेट, सेशन की जानकारी सेव करने के लिए कुकी सेट करने पर निर्भर हो सकता है. सेशन की जानकारी को हर साइट के हिसाब से सेव किया जाता है. इसलिए, विजेट की ओर से सेट की गई कुकी को उन दूसरी वेबसाइटों पर ऐक्सेस करने की ज़रूरत नहीं होती जहां इसे एम्बेड किया गया है. Storage Access API तब काम आता है, जब एम्बेड किया गया तीसरे पक्ष का विजेट, अलग-अलग ऑरिजिन पर एक ही जानकारी शेयर करने पर निर्भर होता है. उदाहरण के लिए, लॉग-इन किए गए सेशन की जानकारी या प्राथमिकताओं के लिए.
• स्टोरेज पार्टीशनिंग, अलग-अलग साइटों पर मौजूद iframe के लिए, मौजूदा JavaScript स्टोरेज मेकेनिज़्म का इस्तेमाल करने का एक तरीका है. इससे, हर साइट के हिसाब से स्टोरेज को बांटा जा सकता है. इससे, किसी वेबसाइट में एम्बेड किए गए स्टोरेज को दूसरी वेबसाइटों पर एम्बेड किए गए उसी स्टोरेज से ऐक्सेस नहीं किया जा सकता.
• मिलती-जुलती वेबसाइट के सेट (आरडब्ल्यूएस) की मदद से कोई संगठन अलग-अलग साइटों के बीच के संबंधों के बारे में एलान करता है. इससे ब्राउज़र, खास कामों के लिए बिना बंटे हुए कुकी और स्टोरेज के सीमित ऐक्सेस को अनुमति देते हैं. साइटों को अब भी Storage Access API के ज़रिए ऐक्सेस का अनुरोध करना होगा. हालांकि, सेट में शामिल साइटों को, उपयोगकर्ता के प्रॉम्प्ट के बिना ऐक्सेस दिया जा सकता है.
• Federated Credential Management (FedCM), पहचान की पुष्टि करने की सेवाओं के लिए, निजता बनाए रखने से जुड़ा एक सुझाव है. Storage Access API, लॉगिन के बाद बिना बंटे हुए कुकी और स्टोरेज को ऐक्सेस करने से जुड़ा है. इस्तेमाल के कुछ उदाहरणों के लिए, FedCM, Storage Access API का विकल्प उपलब्ध कराता है. साथ ही, यह ज़्यादा बेहतर विकल्प हो सकता है, क्योंकि इसमें लॉगिन के लिए ब्राउज़र प्रॉम्प्ट की सुविधा होती है. हालांकि, FedCM को अपनाने के लिए, आम तौर पर आपको अपने कोड में कुछ और बदलाव करने पड़ते हैं. उदाहरण के लिए, इसके एचटीटीपी एंडपॉइंट के साथ काम करने के लिए.
• धोखाधड़ी रोकने, विज्ञापन से जुड़े, और मेज़रमेंट एपीआई भी उपलब्ध हैं. Storage Access API का मकसद इन समस्याओं को हल करना नहीं है.

Storage Access API का इस्तेमाल करना

Storage Access API में, प्रॉमिस पर आधारित दो तरीके होते हैं:

• Document.hasStorageAccess() (Chrome 125 से, यह Document.hasUnpartitionedCookieAccess() के तौर पर भी उपलब्ध है)
• Document.requestStorageAccess()

यह Permissions API के साथ भी इंटिग्रेट होता है. इससे, तीसरे पक्ष के कॉन्टेक्स्ट में स्टोरेज ऐक्सेस करने की अनुमति का स्टेटस देखा जा सकता है. इससे पता चलता है कि document.requestStorageAccess() को कॉल करने की अनुमति अपने-आप मिल जाएगी या नहीं:

• navigator.permissions.query({name: "storage-access"});

hasStorageAccess() तरीके का इस्तेमाल करना

जब कोई साइट पहली बार लोड होती है, तो वह hasStorageAccess() तरीके का इस्तेमाल करके यह देख सकती है कि तीसरे पक्ष की कुकी का ऐक्सेस पहले ही दिया जा चुका है या नहीं.

// Set a hasAccess boolean variable which defaults to false.
let hasAccess = false;

async function handleCookieAccessInit() {
  if (!document.hasStorageAccess) {
    // Storage Access API is not supported so best we can do is
    // hope it's an older browser that doesn't block 3P cookies.
    hasAccess = true;
  } else {
    // Check whether access has been granted using the Storage Access API.
    hasAccess = await document.hasStorageAccess();
    if (!hasAccess) {
      // Handle the lack of access (covered later)
    }
  }
  if (hasAccess) {
    // Use the cookies.
  }
}
handleCookieAccessInit();

Storage Access API, iframe दस्तावेज़ को स्टोरेज का ऐक्सेस सिर्फ़ तब देता है, जब वह requestStorageAccess(), को कॉल करता है. इसलिए, hasStorageAccess() शुरू में गलत वैल्यू दिखा सकता है. उदाहरण के लिए, अगर उपयोगकर्ता ने डिफ़ॉल्ट रूप से तीसरे पक्ष की कुकी ब्लॉक की हैं. (हालांकि, साइट के हिसाब से उपयोगकर्ता की सेटिंग में, किसी साइट पर कुकी को ऐक्सेस करने की अनुमति भी दी जा सकती है. भले ही, उपयोगकर्ता ने डिफ़ॉल्ट रूप से तीसरे पक्ष की कुकी को ब्लॉक किया हो.) इस एपीआई का इस्तेमाल करके, iframe में एक ही ऑरिजिन से नेविगेट करने पर स्टोरेज का ऐक्सेस बना रहता है. ऐसा इसलिए किया जाता है, ताकि उन पेजों के लिए फिर से लोड करने की अनुमति दी जा सके जिनके लिए एचटीएमएल दस्तावेज़ के शुरुआती अनुरोध में कुकी मौजूद होनी चाहिए.

requestStorageAccess() का इस्तेमाल करें

अगर iframe के पास ऐक्सेस नहीं है, तो उसे requestStorageAccess() तरीके का इस्तेमाल करके ऐक्सेस का अनुरोध करना पड़ सकता है:

if (!hasAccess) {
  try {
    await document.requestStorageAccess();
  } catch (err) {
    // Access was not granted and it may be gated behind an interaction
    return;
  }
}

पहली बार अनुरोध करने पर, उपयोगकर्ता को ब्राउज़र प्रॉम्प्ट के ज़रिए इस ऐक्सेस को स्वीकार करना पड़ सकता है. इसके बाद, प्रॉमिस रिज़ॉल्व हो जाएगा. अगर await का इस्तेमाल किया जाता है, तो प्रॉमिस अस्वीकार हो जाएगा और एक अपवाद मिलेगा.

गलत इस्तेमाल को रोकने के लिए, ब्राउज़र पर दिखने वाला यह प्रॉम्प्ट सिर्फ़ उपयोगकर्ता के इंटरैक्शन के बाद दिखेगा. इसलिए, requestStorageAccess() को iframe लोड होने के तुरंत बाद कॉल करने के बजाय, उपयोगकर्ता के ट्रिगर किए गए इवेंट हैंडलर से कॉल किया जाना चाहिए:

async function doClick() {

  // Only do this extra check if access hasn't already been given
  // based on the hasAccess variable.
  if (!hasAccess) {
    try {
      await document.requestStorageAccess();
      hasAccess = true; // Can assume this was true if requestStorageAccess() did not reject.
    } catch (err) {
      // Access was not granted.
      return;
    }
  }

  if (hasAccess) {
    // Use the cookies
  }
}

document.querySelector('#my-button').addEventListener('click', doClick);

अनुमति के लिए प्रॉम्प्ट

जब उपयोगकर्ता पहली बार बटन पर क्लिक करता है, तो ज़्यादातर मामलों में ब्राउज़र प्रॉम्प्ट अपने-आप दिखेगा. आम तौर पर, यह पता बार में दिखता है. यहां दिए गए स्क्रीनशॉट में, Chrome के प्रॉम्प्ट का उदाहरण दिखाया गया है. हालांकि, अन्य ब्राउज़र में भी इसी तरह का यूज़र इंटरफ़ेस (यूआई) होता है:

ऐसा हो सकता है कि ब्राउज़र प्रॉम्प्ट को स्किप कर दे और कुछ मामलों में अनुमति अपने-आप मिल जाए:

• अगर प्रॉम्प्ट स्वीकार करने के बाद, पिछले 30 दिनों में पेज और iframe का इस्तेमाल किया गया हो.
• अगर एम्बेड किया गया iframe, Related Website Set का हिस्सा है.
• अगर स्टोरेज ऐक्सेस के लिए, FedCM का इस्तेमाल भरोसेमंद सिग्नल के तौर पर किया जाता है.
• Firefox में, जानी-पहचानी वेबसाइटों (जिनके साथ आपने टॉप लेवल पर इंटरैक्ट किया है) के लिए, पहले पांच बार प्रॉम्प्ट को स्किप कर दिया जाता है.

इसके अलावा, कुछ मामलों में बिना प्रॉम्प्ट दिखाए ही, पेमेंट के तरीके को अपने-आप अस्वीकार किया जा सकता है:

• अगर उपयोगकर्ता ने पहले कभी उस साइट पर विज़िट नहीं किया है और उससे इंटरैक्ट नहीं किया है जो iframe को टॉप-लेवल दस्तावेज़ के तौर पर इस्तेमाल करती है, न कि iframe में. इसका मतलब है कि Storage Access API सिर्फ़ उन एम्बेड की गई साइटों के लिए काम का है जिन्हें उपयोगकर्ताओं ने पहले, पहले पक्ष (ग्राहक) के तौर पर विज़िट किया है.
• अगर उपयोगकर्ता के इंटरैक्शन के बाद, प्रॉम्प्ट की पहले से मंज़ूरी लिए बिना, requestStorageAccess() तरीके को उपयोगकर्ता के इंटरैक्शन वाले इवेंट के बाहर कॉल किया जाता है.

पहली बार इस्तेमाल करने पर, उपयोगकर्ता को सूचना दी जाएगी. हालांकि, बाद की विज़िट में, Chrome और Firefox में उपयोगकर्ता के इंटरैक्शन की ज़रूरत नहीं होगी. साथ ही, सूचना के बिना ही requestStorageAccess() की समस्या हल हो जाएगी. ध्यान दें कि Safari में हमेशा उपयोगकर्ता के इंटरैक्शन की ज़रूरत होती है.

कुकी और स्टोरेज का ऐक्सेस, बिना किसी प्रॉम्प्ट या उपयोगकर्ता के इंटरैक्शन के दिया जा सकता है. इसलिए, पेज लोड होने पर requestStorageAccess() को कॉल करके, बिना बंटे हुए कुकी या स्टोरेज का ऐक्सेस पाना अक्सर मुमकिन होता है. ऐसा उन ब्राउज़र पर किया जा सकता है जो इस सुविधा के साथ काम करते हैं (Chrome और Firefox). इससे आपको बिना बंटे हुए कुकी और स्टोरेज को तुरंत ऐक्सेस करने की अनुमति मिल सकती है. साथ ही, उपयोगकर्ता के iframe से इंटरैक्ट करने से पहले भी, आपको बेहतर अनुभव मिल सकता है. कुछ मामलों में, उपयोगकर्ता के इंटरैक्शन का इंतज़ार करने के बजाय, पहले से ही कॉन्टेंट लोड कर लेना बेहतर होता है.

एसएए के लिए, FedCM को सुरक्षा सिग्नल के तौर पर इस्तेमाल करना

FedCM (Federated Credential Management), पहचान की पुष्टि करने की सेवाओं (जैसे, "Sign in with...") के लिए, निजता बनाए रखने से जुड़ा एक सुझाव है. यह तीसरे पक्ष की कुकी या नेविगेशनल रीडायरेक्ट पर निर्भर नहीं करता.

जब कोई उपयोगकर्ता, FedCM की सुविधा के साथ तीसरे पक्ष के आइडेंटिटी प्रोवाइडर (आईडीपी) से एम्बेड किए गए कॉन्टेंट वाले किसी भरोसेमंद पक्ष (आरपी) में लॉग इन करता है, तो एम्बेड किए गए आईडीपी कॉन्टेंट को, टॉप-लेवल की बिना बांटी गई कुकी के स्टोरेज का ऐक्सेस अपने-आप मिल सकता है. FedCM के साथ स्टोरेज का ऐक्सेस अपने-आप चालू होने की सुविधा को चालू करने के लिए, ये शर्तें पूरी होनी चाहिए:

• FedCM की पुष्टि (उपयोगकर्ता के साइन-इन की स्थिति) चालू होनी चाहिए.
• आरपी ने identity-credentials-get अनुमति को सेट करके ऑप्ट-इन किया है. उदाहरण के लिए:

<iframe src="https://idp.example" allow="identity-credentials-get"></iframe>

उदाहरण के लिए, idp.example iframe को rp.example में एम्बेड किया गया है. जब उपयोगकर्ता FedCM की मदद से लॉग इन करता है, तब idp.example iframe अपनी टॉप-लेवल कुकी के लिए स्टोरेज ऐक्सेस का अनुरोध कर सकता है.

rp.example, FedCM को कॉल करता है, ताकि उपयोगकर्ता को आइडेंटिटी प्रोवाइडर idp.example की मदद से लॉग इन किया जा सके:

// The user will be asked to grant FedCM permission.
const cred = await navigator.credentials.get({
  identity: {
    providers: [{
      configURL: 'https://idp.example/fedcm.json',
      clientId: '123',
    }],
  },
});

उपयोगकर्ता के लॉग इन करने के बाद, आईडीपी idp.example iframe में मौजूद requestStorageAccess() को कॉल कर सकता है. हालांकि, ऐसा तब ही किया जा सकता है, जब आरपी ने अनुमतियों से जुड़ी नीति के तहत इसकी अनुमति दी हो. एम्बेड किए गए कॉन्टेंट को, अपनी टॉप-लेवल कुकी के स्टोरेज का ऐक्सेस अपने-आप मिल जाएगा. इसके लिए, उपयोगकर्ता को इसे चालू करने या किसी अन्य अनुमति वाले प्रॉम्प्ट की ज़रूरत नहीं होगी:

// Make this call within the embedded IdP iframe:

// No user gesture is needed, and the storage access will be auto-granted.
await document.requestStorageAccess();

// This returns `true`.
const hasAccess = await document.hasStorageAccess();

यह अनुमति सिर्फ़ तब तक अपने-आप मिलेगी, जब तक उपयोगकर्ता FedCM का इस्तेमाल करके साइन इन रहेगा. पहचान की पुष्टि करने की सुविधा बंद होने के बाद, स्टोरेज का ऐक्सेस देने के लिए, एसएए की स्टैंडर्ड ज़रूरी शर्तें लागू होती हैं.

कुकी के अलावा, स्टोरेज के अन्य तरीकों के लिए Storage Access API

requestStorageAccess कॉल में types पैरामीटर पास करके, बिना बांटे गए लोकल स्टोरेज को ऐक्सेस करने का अनुरोध किया जा सकता है. उदाहरण के लिए, बिना सेक्शन वाले लोकल स्टोरेज का ऐक्सेस पाने का अनुरोध करने के लिए, requestStorageAccess({localStorage: true}) को कॉल किया जा सकता है.

अगर तीसरे पक्ष की कुकी चालू हैं, तो यह तरीका उपयोगकर्ता को ऐक्सेस दे देगा. इसके लिए, उपयोगकर्ता को चालू करने या अनुमति मांगने की ज़रूरत नहीं होगी. अगर उपयोगकर्ता ने तीसरे पक्ष की कुकी बंद कर दी हैं, तो उसे स्टोरेज का ऐक्सेस देने से पहले सूचना दी जाएगी.

सबसे पहले, देखें कि ब्राउज़र के पास स्टोरेज का ऐक्सेस पहले से है या नहीं:

async function hasCookieAccess(){
  // Check if Storage Access API is supported
  if (!document.requestStorageAccess) {
    // Storage Access API is not supported, so we assume it's an older browser that doesn't partition storage.
    throw new Error("requestStorageAccess is not supported")
  }

  // Check if access has already been granted or if the user has 3-party cookies enabled
  return document.hasStorageAccess();
}

अगर तीसरे पक्ष की कुकी चालू हैं, तो स्टोरेज का ऐक्सेस पाने का अनुरोध करें:

// Request storage access and return the storage handle
async function requestStorageHandle(){
// You can request for multiple types of non-cookie storage
// at once, or request for all of them with all:true
return document.requestStorageAccess({all:true});
}

अगर तीसरे पक्ष की कुकी ब्लॉक की गई हैं (उदाहरण के लिए, गुप्त मोड में), तो क्वेरी की अनुमतियों की जांच करें. इससे यह तय किया जा सकेगा कि उपयोगकर्ता को प्रॉम्प्ट दिखाना है या नहीं. navigator.permissions.query({name: 'storage-access'})अनुमति की स्थिति में ये वैल्यू हो सकती हैं:

• granted. उपयोगकर्ता ने पहले ही ऐक्सेस दे दिया है. उपयोगकर्ता को अतिरिक्त प्रॉम्प्ट दिखाए बिना, बिना बांटे गए स्टोरेज का ऐक्सेस पाने के लिए requestStorageAccess को कॉल करें.
• prompt. उपयोगकर्ता ने अब तक ऐक्सेस नहीं दिया है. क्लिक लिसनर सेट करें और उपयोगकर्ता के इंटरैक्शन के बाद, requestStorageAccess को फिर से कॉल करें.
• error. इस अनुमति का इस्तेमाल नहीं किया जा सकता. अगर Storage Access API काम करता है, तो हो सकता है कि यह अनुमति भी काम करे.

// Returns `granted`, or `prompt`; or throws an error if storage-access
// permission is not supported
async function getStorageAccessPermission(){
  // Check the storage-access permission
  // Wrap this in a try/catch for browsers that support the
  // Storage Access API but not this permission check
    return navigator.permissions.query({name: 'storage-access'});
}

कुकी के बिना बांटे गए स्टोरेज को मैनेज करने के लिए, इस पूरे फ़्लो को लागू किया जा सकता है:

async function getStorageHandle() {
    // Check if the user has 3-party cookie access
    if (await hasCookieAccess()) {
    // If the user has access, requestStorageAccess() will resolve automatically
        return requestStorageHandle();
    }

    // If the browser blocks third party cookies, check if the user has
    // accepted the prompt and granted access. If they have,
    // requestStorageAccess() will resolve automatically
    const permission = await getStorageAccessPermission();
    if (permission == 'granted') { // User has seen prompt and granted access
        return requestStorageHandle();
    }

    // Wait for user activation to prompt the user again
    // (or put your silent failure logic here instead)
    return new Promise((resolve, reject) => {
        document.querySelector('#myButton').addEventListener(e => {
            requestStorageHandle().then(resolve, reject);
        })
    })
}

// Use your storage
getStorageHandle().then(handle=>{
    handle.indexedDB.open(...);
}).catch(() => {
    // If the promise is rejected, you can use regular partitioned storage
    indexedDB.open(...);
})

स्टोरेज ऐक्सेस हेडर का इस्तेमाल करके बाद में लोड करना

Storage Access Headers, एम्बेड किए गए कॉन्टेंट को लोड करने का एक बेहतर तरीका है. इसमें iframe के अलावा अन्य संसाधन भी शामिल हैं. हमारा सुझाव है कि आप इस तरीके का इस्तेमाल करें. यह सुविधा Chrome 133 से उपलब्ध है. Storage Access Headers की मदद से, ब्राउज़र यह पहचान सकता है कि उपयोगकर्ता ने मौजूदा कॉन्टेक्स्ट में, तीसरे पक्ष के ऑरिजिन को storage-access अनुमति पहले ही दे दी है. साथ ही, बाद की विज़िट के दौरान, ब्राउज़र उन संसाधनों को लोड कर सकता है जिनके पास बिना बंटवारा की गई कुकी का ऐक्सेस होता है.

स्टोरेज ऐक्सेस हेडर का फ़्लो

स्टोरेज ऐक्सेस हेडर की मदद से, बाद में पेजों पर आने वाले लोगों के लिए यह फ़्लो ट्रिगर होगा:

1. उपयोगकर्ता ने पहले website.example पर जाकर, calendar.example रिसॉर्स को एम्बेड किया हो और document.requestStorageAccess() कॉल के साथ storage-access को अनुमति दी हो.
2. उपयोगकर्ता website.example पर जाता है, जिसमें calendar.example रिसोर्स को फिर से एम्बेड किया गया है. इस अनुरोध के पास अब भी कुकी का ऐक्सेस नहीं है. हालांकि, उपयोगकर्ता ने पहले storage-access अनुमति दी थी. साथ ही, फ़ेच में storage-access हेडर शामिल है, ताकि यह पता चल सके कि बिना बंटवारा की गई कुकी का ऐक्सेस उपलब्ध है, लेकिन चालू नहीं है.Sec-Fetch-Storage-Access: inactive
3. calendar.example सर्वर, Activate-Storage-Access: retry; allowed-origin='<origin>' हेडर (इस मामले में, <origin> https://website.example होगा) के साथ जवाब देता है. इससे यह पता चलता है कि रिसॉर्स फ़ेच करने के लिए, storage-access अनुमति के साथ अनपार्टिशन की गई कुकी का इस्तेमाल करना ज़रूरी है.
4. ब्राउज़र, अनुरोध को फिर से भेजता है. इस बार, इसमें बिना बांटी गई कुकी शामिल होती हैं (इस फ़ेच और इसके बाद के फ़ेच के लिए, storage-access अनुमति चालू करना).
5. calendar.example सर्वर, आपके हिसाब से बनाए गए iframe का कॉन्टेंट दिखाता है. जवाब में Activate-Storage-Access: load हेडर शामिल होता है. इससे यह पता चलता है कि ब्राउज़र को storage-access की अनुमति चालू करके कॉन्टेंट लोड करना चाहिए. दूसरे शब्दों में कहें, तो ब्राउज़र को बिना बांटी गई कुकी के ऐक्सेस के साथ कॉन्टेंट लोड करना चाहिए. ऐसा तब होता है, जब document.requestStorageAccess() को कॉल किया गया हो.
6. उपयोगकर्ता एजेंट, storage-access अनुमति का इस्तेमाल करके, बिना बांटी गई कुकी के ऐक्सेस के साथ iframe कॉन्टेंट लोड करता है. इस चरण के बाद, विजेट उम्मीद के मुताबिक काम कर सकता है.

स्टोरेज ऐक्सेस हेडर का इस्तेमाल करना

यहां दी गई टेबल में, Storage Access हेडर दिए गए हैं.

उदाहरण के लिए, स्टोरेज ऐक्सेस हेडर का इस्तेमाल, किसी तीसरे पक्ष से इमेज लोड करने के लिए किया जा सकता है:

  // On the client side
  <img src="https://server.example/image">

इस मामले में, server.example को सर्वर साइड पर यह लॉजिक लागू करना चाहिए:

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

  if (storageAccessHeader === 'inactive') {
    // The user needs to grant permission, trigger a prompt

    // Check if the requesting origin is allowed
    // to send credentialed requests to this server.
    // Assuming the `validate_origin(origin)` method is previously defined:
    if (!validate_origin(req.headers.origin)) {
      res.status(401).send(req.headers.origin +
        ' is not allowed to send credentialed requests to this server.');
      return;
    }
    // 'retry' header value indicates that the content load request should be re-sent after the user has granted permissions
    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')
  }
});

Storage Access API के डेमो में, Storage Access Headers का इस्तेमाल करके तीसरे पक्ष का कॉन्टेंट एम्बेड किया जाता है. इसमें iframe के अलावा कोई दूसरी इमेज भी शामिल है.

storage-access अनुमति के लिए क्वेरी का इस्तेमाल करना

यह देखने के लिए कि उपयोगकर्ता के इंटरैक्शन के बिना ऐक्सेस दिया जा सकता है या नहीं, storage-access अनुमति की स्थिति देखें. अगर उपयोगकर्ता की कार्रवाई की ज़रूरत नहीं है, तो requestStoreAccess() कॉल को सिर्फ़ तब करें, जब इंटरैक्शन की ज़रूरत हो. ऐसा न करने पर, कॉल करने पर यह काम नहीं करेगा.

इससे आपको अलग-अलग कॉन्टेंट दिखाने का विकल्प मिलता है. जैसे, लॉगिन बटन. इससे आपको प्रॉम्प्ट की ज़रूरत नहीं पड़ती.

यहां दिए गए कोड में, पिछले उदाहरण में storage-access अनुमति की जांच करने की सुविधा जोड़ी गई है:

// Set a hasAccess boolean variable which defaults to false except for
// browsers which don't support the API - where we assume
// such browsers also don't block third-party cookies.
let hasAccess = false;

async function hasCookieAccess() {
  // Check if Storage Access API is supported
  if (!document.requestStorageAccess) {
    // Storage Access API is not supported so best we can do is
    // hope it's an older browser that doesn't block 3P cookies.
    return true;
  }

  // Check if access has already been granted
  if (await document.hasStorageAccess()) {
    return true;
  }

  // Check the storage-access permission
  // Wrap this in a try/catch for browsers that support the
  // Storage Access API but not this permission check
  // (e.g. Safari and earlier versions of Firefox).
  let permission;
  try {
    permission = await navigator.permissions.query(
      {name: 'storage-access'}
    );
  } catch (error) {
    // storage-access permission not supported. Assume no cookie access.
    return false;
  }

    if (permission) {
    if (permission.state === 'granted') {
      // Permission has previously been granted so can just call
      // requestStorageAccess() without a user interaction and
      // it will resolve automatically.
      try {
        await document.requestStorageAccess();
        return true;
      } catch (error) {
        // This shouldn't really fail if access is granted, but return false
        // if it does.
        return false;
      }
    } else if (permission.state === 'prompt') {
      // Need to call requestStorageAccess() after a user interaction
      // (potentially with a prompt). Can't do anything further here,
      // so handle this in the click handler.
      return false;
          } else if (permission.state === 'denied') {
            // Not used: see https://github.com/privacycg/storage-access/issues/149
      return false;
          }
    }

  // By default return false, though should really be caught by earlier tests.
  return false;
}

async function handleCookieAccessInit() {
  hasAccess = await hasCookieAccess();

  if (hasAccess) {
    // Use the cookies.
  }
}

handleCookieAccessInit();

सैंडबॉक्स किए गए iframe

सैंडबॉक्स किए गए iframe में Storage Access API का इस्तेमाल करते समय, सैंडबॉक्स की इन अनुमतियों की ज़रूरत होती है:

• Storage Access API को ऐक्सेस करने की अनुमति देने के लिए, allow-storage-access-by-user-activation ज़रूरी है.
• एपीआई को कॉल करने के लिए, JavaScript का इस्तेमाल करने की अनुमति देने के लिए allow-scripts ज़रूरी है.
• allow-same-origin की ज़रूरत, एक ही ऑरिजिन की कुकी और अन्य स्टोरेज को ऐक्सेस करने की अनुमति देने के लिए होती है.

उदाहरण के लिए:

<iframe sandbox="allow-storage-access-by-user-activation
                 allow-scripts
                 allow-same-origin"
        src="..."></iframe>

कुकी से जुड़ी ज़रूरी शर्तें

Chrome में Storage Access API की मदद से ऐक्सेस करने के लिए, क्रॉस-साइट कुकी को इन दो एट्रिब्यूट के साथ सेट किया जाना चाहिए:

• SameSite=None - इसकी ज़रूरत कुकी को दूसरी साइट के तौर पर मार्क करने के लिए होती है
• Secure - इससे यह पक्का होता है कि सिर्फ़ एचटीटीपीएस साइटों से सेट की गई कुकी को ऐक्सेस किया जा सकता है.

Firefox और Safari में, कुकी डिफ़ॉल्ट रूप से SameSite=None पर सेट होती हैं. साथ ही, ये SAA को Secure कुकी तक सीमित नहीं करती हैं. इसलिए, इन एट्रिब्यूट की ज़रूरत नहीं होती. हमारा सुझाव है कि SameSite एट्रिब्यूट के बारे में साफ़ तौर पर बताया जाए और हमेशा Secure कुकी का इस्तेमाल किया जाए.

टॉप-लेवल पेज का ऐक्सेस

Storage Access API का इस्तेमाल, एम्बेड किए गए iframe में तीसरे पक्ष की कुकी का ऐक्सेस चालू करने के लिए किया जाता है.

ऐसे भी कई उदाहरण हैं जब टॉप-लेवल पेज को तीसरे पक्ष की कुकी ऐक्सेस करने की ज़रूरत होती है. उदाहरण के लिए, कुकी की वजह से प्रतिबंधित की गई इमेज या स्क्रिप्ट. साइट के मालिक इन्हें सीधे तौर पर टॉप-लेवल के दस्तावेज़ में शामिल करना चाहते हैं, न कि किसी iframe में. इस समस्या को हल करने के लिए, Chrome ने Storage Access API के एक्सटेंशन का सुझाव दिया है. इसमें एकrequestStorageAccessFor() तरीका जोड़ा गया है.

requestStorageAccessFor() तरीका

requestStorageAccessFor() तरीका, requestStorageAccess() तरीके की तरह ही काम करता है. हालांकि, यह टॉप-लेवल के संसाधनों के लिए होता है. इसका इस्तेमाल सिर्फ़ मिलती-जुलती वेबसाइट के सेट में शामिल साइटों के लिए किया जा सकता है, ताकि तीसरे पक्ष की कुकी को सामान्य ऐक्सेस देने से रोका जा सके.

requestStorageAccessFor() का इस्तेमाल कैसे किया जाता है, इस बारे में ज़्यादा जानने के लिए मिलती-जुलती वेबसाइट के सेट: डेवलपर गाइड पढ़ें.

top-level-storage-access अनुमति से जुड़ी क्वेरी

storage-access की अनुमति की तरह ही, top-level-storage-access की अनुमति भी होती है. इससे यह पता चलता है कि requestStorageAccessFor() के लिए ऐक्सेस दिया जा सकता है या नहीं.

RWS के साथ इस्तेमाल करने पर, Storage Access API किस तरह अलग होता है?

मिलती-जुलती वेबसाइटों के सेट को Storage Access API के साथ इस्तेमाल करने पर, कुछ अतिरिक्त सुविधाएं मिलती हैं. इनके बारे में यहां बताया गया है:

डेमो: कुकी सेट करना और उन्हें ऐक्सेस करना

यहां दिए गए डेमो में दिखाया गया है कि डेमो की पहली स्क्रीन में सेट की गई कुकी को, डेमो की दूसरी साइट में एम्बेड किए गए फ़्रेम में कैसे ऐक्सेस किया जा सकता है:

storage-access-api-demo.glitch.me

डेमो के लिए, ऐसे ब्राउज़र की ज़रूरत होती है जिसमें तीसरे पक्ष की कुकी बंद हों:

• Chrome 118 या इसके बाद का वर्शन, जिसमें chrome://flags/#test-third-party-cookie-phaseout फ़्लैग सेट हो और ब्राउज़र को फिर से शुरू किया गया हो.
• Firefox
• Safari

डेमो: लोकल स्टोरेज सेट करना

यहां दिए गए डेमो में, Storage Access API का इस्तेमाल करके, तीसरे पक्ष के iframe से बिना बंटवारा किए गए ब्रॉडकास्ट चैनलों को ऐक्सेस करने का तरीका दिखाया गया है:

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

डेमो के लिए, Chrome 125 या उसके बाद का वर्शन होना चाहिए. साथ ही, test-third-party-cookie-phaseout फ़्लैग चालू होना चाहिए.

संसाधन

• तीसरे पक्ष की कुकी का ऐक्सेस देने वाले स्पेसिफ़िकेशन पढ़ें या समस्याएं फ़ॉलो करें और उन्हें हल करें.
• बिना बंटवारा किए गए स्टोरेज का ऐक्सेस देने वाले स्पेसिफ़िकेशन पढ़ें या समस्याएं फ़ॉलो करें और उन्हें हल करें.
• एपीआई से जुड़ा दस्तावेज़ और गाइड.
• मिलती-जुलती वेबसाइट के सेट में Storage Access API इस्तेमाल करने के बारे में Chrome का दस्तावेज़