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

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

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

Document.hasStorageAccess() (Chrome 125 के बाद, यह नए नाम Document.hasUnpartitionedCookieAccess() से भी उपलब्ध है)
Document.requestStorageAccess()

इसे अनुमतियां एपीआई के साथ भी इंटिग्रेट किया जाता है. इससे, तीसरे पक्ष के संदर्भ में स्टोरेज ऐक्सेस करने की अनुमति का स्टेटस देखा जा सकता है. इससे यह पता चलता है कि 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.
    // 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 में किसी दूसरे दस्तावेज़ को पहले ही ऐक्सेस दिया जा चुका है, तो 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);

चेतावनी: किसी उपयोगकर्ता इंटरैक्शन में, requestStorageAccess() को किसी भी अन्य एपीआई (जैसे, hasStorageAccess()) के चालू होने से पहले कॉल किया जाना चाहिए.

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

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 को हमेशा उपयोगकर्ता इंटरैक्शन की ज़रूरत होती है.

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

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

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

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

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

चेतावनी: storage-access अनुमति, Chrome और Firefox पर काम करती है, लेकिन Safari पर नहीं. Safari का इस्तेमाल करने वाले लोगों के लिए, उपयोगकर्ता इंटरैक्शन हमेशा ज़रूरी होता है. हालांकि, ऐक्सेस देने के बाद पेज को रीफ़्रेश करने के खास इस्तेमाल के मामले में ऐसा नहीं होता.

यह कोड, पिछले उदाहरण में 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();

अहम जानकारी: निजता की वजहों से, यह नहीं बताया जा सकता कि प्रॉम्प्ट को दिखाया गया है या नहीं और उसे अस्वीकार किया गया है या नहीं, या ब्राउज़र के अनुभव के आधार पर नहीं दिखाया जाता है—दोनों क्वेरी के लिए फिर से अनुरोध किए जाने पर भी, दोनों मौजूदा स्थिति के रूप में prompt पर वापस आ जाएंगे.

सैंडबॉक्स किए गए 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 के साथ Related Website Sets का इस्तेमाल करने पर, कुछ अन्य सुविधाएं भी उपलब्ध होती हैं. इनके बारे में नीचे दी गई टेबल में बताया गया है:

	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 फ़्लैग चालू होना चाहिए.

संसाधन

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

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

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

Storage Access API क्या है?

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

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

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

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

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

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

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

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

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

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

requestStorageAccessFor() तरीका

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

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

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

डेमो: स्थानीय मेमोरी सेट करना

संसाधन

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

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

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

`requestStorageAccessFor()` तरीका

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