स्टोरेज ऐक्सेस एपीआई

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

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

ब्राउज़र सहायता

  • 119
  • 85
  • 65
  • 11.1

सोर्स

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 का इस्तेमाल करके ऐक्सेस का अनुरोध करना होगा. हालांकि, सेट में शामिल साइटों के लिए, उपयोगकर्ता के प्रॉम्प्ट के बिना भी ऐक्सेस दिया जा सकता है.
  • फ़ेडरेटेड क्रेडेंशियल मैनेजमेंट (FedCM), फ़ेडरेटेड आइडेंटिटी सर्विस के लिए उपयोगकर्ता की निजता को बनाए रखने वाला एक तरीका है. Storage Access API का इस्तेमाल करके, लॉगिन करने के बाद उन कुकी और स्टोरेज को ऐक्सेस किया जा सकता है जिन्हें बांटा नहीं गया है. कुछ मामलों में FedCM, Storage Access API के लिए एक विकल्प देता है. यह बेहतर विकल्प हो सकता है, क्योंकि इसमें लॉगिन पर आधारित ब्राउज़र प्रॉम्प्ट मिलता है. हालांकि, FedCM को अपनाने के लिए आम तौर पर आपको अपने कोड में कुछ और बदलाव करने होते हैं, उदाहरण के लिए इसके एचटीटीपी एंडपॉइंट पर काम करने के लिए.
  • धोखाधड़ी से जुड़े, विज्ञापन से जुड़े, और मेज़रमेंट एपीआई भी मौजूद हैं. साथ ही, Storage Access API का मकसद इन समस्याओं को हल करना नहीं है.

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

Storage Access API में दो तरीके बताए गए हैं, जिनके बारे में वादा किया गया है:

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

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 via the Storage Access API.
    // Note on page load this will always be false initially so we could be
    // skipped in this example, but including for completeness for when this
    // is not so obvious.
    hasAccess = await document.hasStorageAccess();
    if (!hasAccess) {
      // Handle the lack of access (covered later)
    }
  }
  if (hasAccess) {
    // Use the cookies.
  }
}
handleCookieAccessInit();

iframe दस्तावेज़ को requestStorageAccess(), को कॉल करने के बाद ही, स्टोरेज का ऐक्सेस दिया जाता है. इसलिए, hasStorageAccess() शुरुआत में हमेशा गलत वैल्यू दिखाएगा. ऐसा तब नहीं होगा, जब उसी iframe में मौजूद एक ही ऑरिजिन वाले किसी अन्य दस्तावेज़ को पहले से ऐक्सेस दिया गया हो. इस अनुमति को 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 का इस्तेमाल किए जाने पर, अपवाद के तौर पर लागू होगा.

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

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 above did not reject.
    } catch (err) {
      // Access was not granted.
      return;
    }
  }

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

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

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

let handle = null;

async function doClick() {
  if (!handle) {
    try {
      handle = await document.requestStorageAccess({localStorage: true});
    } catch (err) {
      // Access was not granted.
      return;
    }
  }

  // Use handle to access unpartitioned local storage.
  handle.localStorage.setItem('foo', 'bar');
}

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

अनुमति के अनुरोध

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

Chrome Storage Access API की अनुमति के अनुरोध का स्क्रीनशॉट
Chrome से Storage Access API को अनुमति देने का अनुरोध

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

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

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

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

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

कुकी और स्टोरेज का ऐक्सेस, किसी प्रॉम्प्ट या उपयोगकर्ता के इंटरैक्शन के बिना दिया जा सकता है. इसलिए, पेज लोड होने पर requestStorageAccess() को कॉल करके, इसके साथ काम करने वाले ब्राउज़र (Chrome और Firefox) पर उपयोगकर्ता के इंटरैक्शन से पहले, कुकी या स्टोरेज का ऐक्सेस मिल जाता है. इससे आपको उन कुकी और स्टोरेज को तुरंत ऐक्सेस करने की सुविधा मिल सकती है जिन्हें बांटा नहीं गया है. साथ ही, उपयोगकर्ता के 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 older 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') {
            // Currently not used. See:
      // https://github.com/privacycg/storage-access/issues/149
      return false;
          }
    }

  // By default return false, though should really be caught by one of above.
  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 पर सेट होती हैं और वे एसएसए को Secure कुकी तक सीमित नहीं करती हैं. इसलिए, इन एट्रिब्यूट की ज़रूरत नहीं होती है. हमारा सुझाव है कि आप SameSite एट्रिब्यूट के बारे में साफ़ तौर पर जानकारी दें. साथ ही, हमेशा Secure कुकी का इस्तेमाल करें.

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

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

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

requestStorageAccessFor() तरीका

ब्राउज़र सहायता

  • 119
  • 119
  • x
  • x

सोर्स

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

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

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

ब्राउज़र सहायता

  • x
  • x
  • x
  • x

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

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

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

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

संसाधन