Chrome, क्रॉस-साइट ट्रैकिंग को कम करने के लिए, तीसरे पक्ष की कुकी के साथ काम करना बंद कर रहा है. साथ ही, वह स्टोरेज के बंटवारे की सुविधा भी बंद कर रहा है. इस वजह से, उन साइटों और सेवाओं के लिए चुनौती का सामना करना पड़ता है जो पुष्टि करने जैसे कामों के लिए, एम्बेड की गई कॉन्टेक्स्ट में कुकी और अन्य स्टोरेज का इस्तेमाल करती हैं. 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 का इस्तेमाल करके ऐक्सेस का अनुरोध करना होगा. हालांकि, सेट में शामिल साइटों के लिए, उपयोगकर्ता के प्रॉम्प्ट के बिना भी ऐक्सेस दिया जा सकता है.
- फ़ेडरेटेड क्रेडेंशियल मैनेजमेंट (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()
इसे अनुमतियां एपीआई के साथ भी इंटिग्रेट किया जाता है. इससे आपको तीसरे पक्ष के कॉन्टेक्स्ट में स्टोरेज के ऐक्सेस की अनुमति की स्थिति देखने की सुविधा मिलती है. इससे पता चलता है कि 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 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 में मौजूद एक ही ऑरिजिन वाले किसी अन्य दस्तावेज़ को पहले से ऐक्सेस दिया गया हो. इस अनुमति को 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 requestStorageAccess() 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 की अनुमति का अनुरोध](https://developers.google.cn/static/privacy-sandbox/assets/images/storage-access-api-permission-prompt.png?authuser=5&hl=hi)
ब्राउज़र, प्रॉम्प्ट को स्किप कर सकता है और कुछ मामलों में यह अनुमति अपने-आप मिल जाती है:
- अगर प्रॉम्प्ट स्वीकार करने के बाद, पिछले 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 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 के साथ इस्तेमाल किया जाता है, तो कुछ अतिरिक्त सुविधाएं भी उपलब्ध होती हैं. इनके बारे में इस टेबल में बताया गया है:
RWS के बिना | RWS की सुविधा वाले ऐप्लिकेशन | |
---|---|---|
स्टोरेज के ऐक्सेस का अनुरोध करने के लिए, उपयोगकर्ता के जेस्चर की ज़रूरत होती है | ||
ऐक्सेस देने से पहले, उपयोगकर्ता को टॉप-लेवल कॉन्टेक्स्ट में उस स्टोरेज ऑरिजिन पर जाना होगा जिसके लिए अनुरोध किया गया था | ||
पहली बार के यूज़र प्रॉम्प्ट को स्किप किया जा सकता है | ||
अगर पहले ऐक्सेस दे दिया गया है, तो requestStorageAccess को कॉल करने की ज़रूरत नहीं है |
||
मिलती-जुलती वेबसाइट की साइट में सभी अन्य डोमेन को अपने-आप ऐक्सेस देता है | ||
टॉप लेवल पेज ऐक्सेस के लिए requestStorageAccessFor का इस्तेमाल किया जा सकता है |
डेमो: कुकी सेट करना और उन्हें ऐक्सेस करना
इस डेमो में दिखाया गया है कि डेमो की पहली स्क्रीन में, खुद से सेट की गई कुकी को दूसरी साइट में एम्बेड किए गए फ़्रेम से कैसे ऐक्सेस किया जा सकता है:
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 से जुड़ा दस्तावेज़