मिलते-जुलते वेबसाइट सेट: डेवलपर गाइड

मिलती-जुलती वेबसाइट के सेट (RWS) एक वेब प्लैटफ़ॉर्म का तरीका है. इससे, ब्राउज़र को अलग-अलग डोमेन के बीच के संबंधों को समझने में मदद मिलती है. इससे ब्राउज़र को साइट की कुछ सुविधाओं (जैसे, क्रॉस-साइट कुकी के ऐक्सेस की अनुमति देना) को चालू करने और उपयोगकर्ताओं को यह जानकारी दिखाने के लिए अहम फ़ैसले लेने में मदद मिलती है.

Chrome, तीसरे पक्ष की कुकी को बंद कर रहा है. इसलिए, इसका लक्ष्य उपयोगकर्ताओं की निजता को बेहतर बनाते हुए, वेब पर इस्तेमाल के खास उदाहरणों को बनाए रखना है. उदाहरण के लिए, कई साइटें एक ही उपयोगकर्ता अनुभव देने के लिए कई डोमेन का इस्तेमाल करती हैं. संगठन कई बार इस्तेमाल के लिए, अलग-अलग टॉप लेवल डोमेन बनाए रख सकते हैं. जैसे, किसी देश के लिए बने डोमेन या इमेज या वीडियो होस्ट करने के लिए सेवा डोमेन. 'मिलती-जुलती वेबसाइट के सेट' की मदद से, साइटें खास कंट्रोल का इस्तेमाल करके, डोमेन के बीच डेटा शेयर कर सकती हैं.

हाई लेवल पर, मिलती-जुलती वेबसाइट का सेट, डोमेन का ऐसा कलेक्शन होता है जिसके लिए एक "प्राइमरी सेट करें" और एक से ज़्यादा "सदस्यों को सेट करें" विकल्प होते हैं.

यहां दिए गए उदाहरण में, primary में प्राइमरी डोमेन और associatedSites में ऐसे डोमेन की सूची दी गई है जो जुड़े हुए सबसेट की ज़रूरी शर्तों को पूरा करते हैं.

{
  "primary": "https://primary.com",
  "associatedSites": ["https://associate1.com", "https://associate2.com", "https://associate3.com"]
}

मिलती-जुलती वेबसाइट के सेट की सूची, JSON फ़ाइल फ़ॉर्मैट में सार्वजनिक तौर पर देखी जा सकती है. इसे मिलती-जुलती वेबसाइट के सेट GitHub रिपॉज़िटरी में होस्ट किया जाता है. यह सभी सेट के लिए, सोर्स के तौर पर काम करता है. Chrome इस फ़ाइल का इस्तेमाल करता है, ताकि उसे अपने व्यवहार पर लागू किया जा सके.

किसी डोमेन का एडमिन कंट्रोल रखने वाले लोग ही उस डोमेन के साथ सेट बना सकते हैं. सबमिट करने वाले लोगों को यह बताना होगा कि "सेट किए गए सदस्य" का "मुख्य सदस्य" से क्या संबंध है. सेट के सदस्यों में कई तरह के डोमेन शामिल हो सकते हैं. साथ ही, उनका इस्तेमाल के उदाहरण पर आधारित किसी सबसेट का हिस्सा होना ज़रूरी है.

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

सेट सबमिट करने की प्रक्रिया और ज़रूरी शर्तों के बारे में ज़्यादा जानने के लिए, सबमिट करने के दिशा-निर्देश देखें. सबमिट किए गए सेट की पुष्टि करने के लिए, अलग-अलग तकनीकी जांच की जाएगी.

'मिलती-जुलती वेबसाइट के सेट' ऐसे मामलों में इस्तेमाल करना बेहतर होता है जब किसी संगठन को अलग-अलग टॉप लेवल की साइटों पर, एक जैसी पहचान की ज़रूरत होती है.

मिलती-जुलती वेबसाइट के सेट के इस्तेमाल के कुछ उदाहरण यहां दिए गए हैं:

  • देश को पसंद के मुताबिक बनाना. शेयर किए गए इन्फ़्रास्ट्रक्चर पर निर्भर रहते हुए, स्थानीय जगहों के हिसाब से बनाई गई साइटों का इस्तेमाल करना (example.co.uk, example.ca से होस्ट की गई सेवा पर भरोसा कर सकता है).
  • सेवा डोमेन का इंटिग्रेशन. ऐसे सेवा डोमेन का इस्तेमाल करना जिनसे उपयोगकर्ता कभी भी सीधे तौर पर इंटरैक्ट नहीं करते, लेकिन वे उसी संगठन की साइटों (example-cdn.com) पर सेवाएं देते हों.
  • उपयोगकर्ता के कॉन्टेंट को अलग करना. अलग-अलग डोमेन पर डेटा ऐक्सेस करना, जो सुरक्षा की वजहों से, उपयोगकर्ता के अपलोड किए गए कॉन्टेंट को अन्य साइट के कॉन्टेंट से अलग करता है. साथ ही, सैंडबॉक्स किए गए डोमेन को पुष्टि करने (और अन्य) कुकी को ऐक्सेस करने की अनुमति देना. अगर उपयोगकर्ता का अपलोड किया गया ऐसा कॉन्टेंट दिखाया जा रहा है जो काम का नहीं है, तो सबसे सही तरीके अपनाकर, उसे उसी डोमेन पर सुरक्षित तरीके से होस्ट किया जा सकता है.
  • पुष्टि किया गया कॉन्टेंट एम्बेड किया गया. जुड़ी हुई सभी प्रॉपर्टी से एम्बेड किए गए कॉन्टेंट के साथ काम करना. जैसे, टॉप लेवल की साइट पर साइन इन करने वाले व्यक्ति के लिए सीमित वीडियो, दस्तावेज़ या संसाधन.
  • साइन-इन करें. सहयोगी (अफ़िलिएट) प्रॉपर्टी में साइन-इन करने में मदद करना. इस्तेमाल के कुछ उदाहरणों में FedCM API भी सही हो सकता है.
  • Analytics. सेवाओं की क्वालिटी को बेहतर बनाने के लिए, सहयोगी प्रॉपर्टी में उपयोगकर्ता की गतिविधियों के आंकड़े और मेज़रमेंट लागू करना.

Storage Access API

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

  • 119
  • 85
  • 65
  • 11.1

सोर्स

Storage Access API (SAA), एम्बेड किए गए क्रॉस-ऑरिजिन कॉन्टेंट को उस स्टोरेज को ऐक्सेस करने का तरीका बताता है जिसका ऐक्सेस आम तौर पर, पहले पक्ष के कॉन्टेंट में होता है.

एम्बेड किए गए संसाधन SAA के तरीकों का इस्तेमाल करके, यह पता लगा सकते हैं कि उनके पास फ़िलहाल स्टोरेज का ऐक्सेस है या नहीं. साथ ही, वे उपयोगकर्ता एजेंट से ऐक्सेस का अनुरोध भी कर सकते हैं.

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

स्टोरेज का ऐक्सेस देखें और उसका अनुरोध करें

यह देखने के लिए कि उनके पास फ़िलहाल स्टोरेज का ऐक्सेस है या नहीं, एम्बेड की गई साइटें Document.hasStorageAccess() तरीके का इस्तेमाल कर सकती हैं.

इस तरीके से ऐसा प्रॉमिस मिलता है जो बूलियन वैल्यू के साथ रिज़ॉल्व होता है. इससे यह पता चलता है कि दस्तावेज़ के पास पहले से ही कुकी का ऐक्सेस है या नहीं. अगर iframe का ऑरिजिन टॉप फ़्रेम का है, तो भी प्रॉमिस 'सही' दिखाता है.

एम्बेड की गई क्रॉस-साइट कॉन्टेक्स्ट में कुकी के ऐक्सेस का अनुरोध करने के लिए, Document.requestStorageAccess() (rSA) का इस्तेमाल किया जा सकता है.

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

requestStorageAccess() एक प्रॉमिस देता है. यह प्रॉमिस तब मिलता है, जब स्टोरेज का ऐक्सेस दिया गया हो. अगर किसी वजह से ऐक्सेस अस्वीकार किया गया, तो इसकी वजह बताते हुए प्रॉमिस अस्वीकार कर दिया जाएगा.

Chrome में requestStorageAccessFor

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

  • 119
  • 119
  • x
  • x

सोर्स

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

इस वजह से, टॉप लेवल की उन साइटों के लिए Storage Access API को इस्तेमाल करने में चुनौतियां आ रही हैं जो कुकी की ज़रूरत वाली क्रॉस-साइट इमेज या स्क्रिप्ट टैग का इस्तेमाल करती हैं.

इसे ठीक करने के लिए, Chrome ने टॉप लेवल की साइटों के लिए, Document.requestStorageAccessFor() (rSAFor) की मदद से कुछ ऑरिजिन की ओर से स्टोरेज के ऐक्सेस का अनुरोध करने का तरीका लागू किया है.

 document.requestStorageAccessFor('https://target.site')

requestStorageAccessFor() एपीआई को किसी टॉप लेवल दस्तावेज़ से कॉल किया जाता है. उस दस्तावेज़ को भी अभी-अभी उपयोगकर्ता इंटरैक्शन मिला हो. हालांकि, requestStorageAccess() के उलट, Chrome पिछले 30 दिनों के किसी टॉप लेवल दस्तावेज़ में किसी इंटरैक्शन की जांच नहीं करता, क्योंकि उपयोगकर्ता पहले से ही इस पेज पर है.

स्टोरेज ऐक्सेस करने की अनुमतियां देखें

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

navigator.permissions.query() का इस्तेमाल करके, अनुमति के स्टेटस के बारे में क्वेरी की जा सकती है.

अगर आपको मौजूदा कॉन्टेक्स्ट के लिए स्टोरेज ऐक्सेस करने की अनुमति की जांच करनी है, तो आपको 'storage-access' स्ट्रिंग में इसे भेजना होगा:

navigator.permissions.query({name: 'storage-access'})

किसी खास ऑरिजिन के लिए स्टोरेज ऐक्सेस करने की अनुमति देखने के लिए, आपको 'top-level-storage-access' स्ट्रिंग में पास करना होगा:

navigator.permissions.query({name: 'top-level-storage-access', requestedOrigin: 'https://target.site'})

ध्यान दें कि एम्बेड किए गए ऑरिजिन की सुरक्षा को बनाए रखने के लिए, यह सेटिंग सिर्फ़ उन अनुमतियों की जांच करती है जो document.requestStorageAccessFor का इस्तेमाल करके टॉप लेवल दस्तावेज़ ने दी हैं.

अनुमति अपने-आप मिल सकती है या नहीं या इसके लिए उपयोगकर्ता के जेस्चर की ज़रूरत है या नहीं, इसके आधार पर prompt या granted दिखेगा.

हर फ़्रेम मॉडल के हिसाब से

rSA की अनुमतियां हर फ़्रेम पर लागू होती हैं. rSA और rSA के अनुदानों को अलग-अलग अनुमतियों के तौर पर माना जाता है.

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

iframe को रीफ़्रेश करने, फिर से लोड करने या फिर से बनाने के लिए, आपको फिर से ऐक्सेस का अनुरोध करना होगा.

कुकी में SameSite=None और Secure, दोनों एट्रिब्यूट की जानकारी देनी ज़रूरी है. ऐसा इसलिए ज़रूरी है, क्योंकि आरएसए सिर्फ़ उन कुकी का ऐक्सेस देता है जिन्हें पहले से ही क्रॉस-साइट कॉन्टेक्स्ट में इस्तेमाल के लिए मार्क किया गया है.

SameSite=Lax, SameSite=Strict या बिना SameSite एट्रिब्यूट वाली कुकी को सिर्फ़ पहले पक्ष के इस्तेमाल के लिए इस्तेमाल किया जा सकता है. इन्हें आरएसए पर ध्यान दिए बिना, क्रॉस-साइट कॉन्टेक्स्ट में कभी भी शेयर नहीं किया जाएगा.

सुरक्षा

rSAFor, सबरिसॉर्स अनुरोधों के लिए, क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग (सीओआरएस) हेडर या संसाधनों पर crossorigin एट्रिब्यूट की ज़रूरत होती है, ताकि साफ़ तौर पर ऑप्ट-इन किया जा सके.

लागू करने के उदाहरण

एम्बेड किए गए क्रॉस-ऑरिजिन iframe से स्टोरेज के ऐक्सेस का अनुरोध करें

Top-level.site पर एम्बेड की गई साइट को दिखाने वाला डायग्राम
किसी दूसरी साइट पर एम्बेड में requestStorageAccess() का इस्तेमाल करना.

यह देखना कि आपके पास स्टोरेज का ऐक्सेस है या नहीं

आपके पास पहले से स्टोरेज का ऐक्सेस है या नहीं, यह देखने के लिए document.hasStorageAccess() का इस्तेमाल करें.

अगर प्रॉमिस सही हो जाता है, तो क्रॉस-साइट कॉन्टेक्स्ट में स्टोरेज को ऐक्सेस किया जा सकता है. अगर यह नीति गलत है, तो आपको स्टोरेज के ऐक्सेस का अनुरोध करना होगा.

document.hasStorageAccess().then((hasAccess) => {
    if (hasAccess) {
      // You can access storage in this context
    } else {
      // You have to request storage access
    }
});

स्टोरेज के ऐक्सेस का अनुरोध करें

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

अगर अनुमति granted है, तो document.requestStorageAccess() को कॉल किया जा सकता है. ऐसा करने पर, उपयोगकर्ता के जेस्चर के बिना ही यह प्रोसेस पूरी हो जाएगी.

अगर अनुमति की स्थिति prompt है, तो आपको बटन पर क्लिक करने जैसे किसी उपयोगकर्ता जेस्चर के बाद document.requestStorageAccess() कॉल शुरू करना होगा.

उदाहरण:

navigator.permissions.query({name: 'storage-access'}).then(res => {
  if (res.state === 'granted') {
    // Permission has already been granted
    // You can request storage access without any user gesture
    rSA();
  } else if (res.state === 'prompt') {
    // Requesting storage access requires user gesture
    // For example, clicking a button
    const btn = document.createElement("button");
    btn.textContent = "Grant access";
    btn.addEventListener('click', () => {
      // Request storage access
      rSA();
    });
    document.body.appendChild(btn);
  }
});

function rSA() {
  if ('requestStorageAccess' in document) {
    document.requestStorageAccess().then(
      (res) => {
        // Use storage access
      },
      (err) => {
        // Handle errors
      }
    );
  }
}

फ़्रेम, नेविगेशन या सबरिसॉर्स में आने वाले अनुरोधों को, क्रॉस-साइट कुकी ऐक्सेस करने की अनुमति अपने-आप मिल जाएगी. hasStorageAccess(), मिलती-जुलती वेबसाइट के इसी सेट से सही और क्रॉस-साइट कुकी दिखाता है. इन कुकी को उन अनुरोधों पर भेजा जाएगा. इसके लिए, कोई अतिरिक्त JavaScript कॉल नहीं करना होगा.

इस डायग्राम में दिखाया गया है कि requestStorageAccessFor() का इस्तेमाल टॉप लेवल साइट पर किया जा रहा है, न कि किसी एम्बेड में नहीं
किसी टॉप लेवल साइट पर, किसी अलग ऑरिजिन के लिए requestStorageAccessFor() का इस्तेमाल करना

टॉप लेवल साइटें, requestStorageAccessFor() का इस्तेमाल करके, कुछ ऑरिजिन की ओर से स्टोरेज के ऐक्सेस का अनुरोध कर सकती हैं.

hasStorageAccess() सिर्फ़ यह जांचता है कि कॉल करने वाली साइट के पास स्टोरेज का ऐक्सेस है या नहीं. इसलिए, टॉप लेवल की कोई साइट किसी अन्य ऑरिजिन के लिए अनुमतियों की जांच कर सकती है.

यह जानने के लिए कि उपयोगकर्ता को निर्देश दिया जाएगा या तय किए गए ऑरिजिन को स्टोरेज का ऐक्सेस पहले से दिया गया है या नहीं, navigator.permissions.query({name: 'top-level-storage-access', requestedOrigin: 'https://target.site'}) पर कॉल करें.

अगर अनुमति granted है, तो document.requestStorageAccessFor('https://target.site') पर कॉल करें. यह सुविधा बिना किसी यूज़र जेस्चर के काम करेगी.

अगर अनुमति prompt है, तो आपको उपयोगकर्ता जेस्चर के पीछे document.requestStorageAccessFor('https://target.site') कॉल को हुक करना होगा, जैसे कि एक बटन क्लिक.

उदाहरण:

navigator.permissions.query({name:'top-level-storage-access',requestedOrigin: 'https://target.site'}).then(res => {
  if (res.state === 'granted') {
    // Permission has already been granted
    // You can request storage access without any user gesture
    rSAFor();
  } else if (res.state === 'prompt') {
    // Requesting storage access requires user gesture
    // For example, clicking a button
    const btn = document.createElement("button");
    btn.textContent = "Grant access";
    btn.addEventListener('click', () => {
      // Request storage access
      rSAFor();
    });
    document.body.appendChild(btn);
  }
});

function rSAFor() {
  if ('requestStorageAccessFor' in document) {
    document.requestStorageAccessFor().then(
      (res) => {
        // Use storage access
      },
      (err) => {
        // Handle errors
      }
    );
  }
}

requestStorageAccessFor() कॉल पूरे होने के बाद, क्रॉस-साइट अनुरोधों में कुकी को शामिल किया जाएगा. ऐसा तब होगा, जब उनमें सीओआरएस या क्रॉसऑरिजिन एट्रिब्यूट शामिल हो. इसलिए, हो सकता है कि साइटें अनुरोध को ट्रिगर करने से पहले इंतज़ार करना चाहें.

अनुरोधों में credentials: 'include' विकल्प का इस्तेमाल किया जाना चाहिए. साथ ही, संसाधनों में crossorigin="use-credentials" एट्रिब्यूट शामिल होना चाहिए.

function checkCookie() {
    fetch('https://related-website-sets.glitch.me/getcookies.json', {
        method: 'GET',
        credentials: 'include'
      })
      .then((response) => response.json())
      .then((json) => {
      // Do something
      });
  }

स्थानीय तौर पर टेस्ट करने का तरीका

ज़रूरी शर्तें

स्थानीय तौर पर, मिलती-जुलती वेबसाइट के सेट की जांच करने के लिए, कमांड लाइन से लॉन्च किए गए Chrome 119 या उसके बाद के वर्शन का इस्तेमाल करें. साथ ही, test-third-party-cookie-phaseout का Chrome फ़्लैग चालू करें.

Chrome फ़्लैग चालू करें

ज़रूरी Chrome फ़्लैग को चालू करने के लिए, पता बार से chrome://flags#test-third-party-cookie-phaseout पर जाएं और फ़्लैग को Enabled में बदलें. फ़्लैग बदलने के बाद ब्राउज़र को रीस्टार्ट करना न भूलें.

Chrome को स्थानीय तौर पर घोषित किए गए मिलती-जुलती वेबसाइट के सेट के साथ लॉन्च करने के लिए, एक JSON ऑब्जेक्ट बनाएं. इसमें ऐसे यूआरएल शामिल हों जो किसी सेट के सदस्य हों और उसे --use-related-website-set को पास कर दें.

Chromium को फ़्लैग के साथ चलाने के तरीके के बारे में ज़्यादा जानें.

--use-related-website-set="{\"primary\": \"https://related-website-sets.glitch.me\", \"associatedSites\": [\"https://rws-member-1.glitch.me\"]}" \
https://related-website-sets.glitch.me/

उदाहरण

मिलती-जुलती वेबसाइट के सेट को स्थानीय तौर पर चालू करने के लिए, आपको chrome://flags में test-third-party-cookie-phaseout को चालू करना होगा. साथ ही, कमांड-लाइन से --use-related-website-set फ़्लैग के साथ Chrome को लॉन्च करना होगा. इसमें JSON ऑब्जेक्ट के साथ, ऐसे यूआरएल शामिल होते हैं जो किसी सेट के सदस्य होते हैं.

--use-related-website-set="{\"primary\": \"https://related-website-sets.glitch.me\", \"associatedSites\": [\"https://rws-member-1.glitch.me\"]}" \
https://related-website-sets.glitch.me/

यह पुष्टि करना कि आपके पास क्रॉस-साइट कुकी का ऐक्सेस है

जिन साइटों की जांच हो रही है उनसे एपीआई (rSA या rSAFor) को कॉल करें और क्रॉस-साइट कुकी के ऐक्सेस की पुष्टि करें.

डोमेन के बीच का संबंध बताने और यह बताने के लिए कि वे किस सबसेट का हिस्सा हैं, यह तरीका अपनाएं:

  1. काम के डोमेन की पहचान करें. इसमें सेट प्राइमरी और सेट मेंबर शामिल हैं, जो मिलती-जुलती वेबसाइट के सेट का हिस्सा होंगे. यह भी पहचान करें कि सेट में शामिल हर सदस्य किस सबसेट टाइप से जुड़ा है.
  2. पक्का करें कि सेट करने की ज़रूरी शर्तें और सेट पुष्टि करने की ज़रूरी शर्तें पूरी हों.
  3. मिलती-जुलती वेबसाइट के सेट का एलान, सही JSON फ़ॉर्मैट में करें.
  4. related_website_sets.JSON पर पुल अनुरोध (पीआर) बनाकर, मिलती-जुलती वेबसाइट के सेट को सबमिट करें. यहां Chrome मिलती-जुलती वेबसाइट के सेट की कैननिकल सूची को होस्ट करेगा. (पीआर बनाने के लिए, GitHub खाता होना ज़रूरी है. साथ ही, सूची में योगदान देने के लिए, आपको योगदान देने वालों के लाइसेंस के समझौते (सीएलए) पर हस्ताक्षर करना होगा.

पीआर बन जाने के बाद, कई चरणों की जांच की जाएगी. इससे यह पुष्टि की जाएगी कि दूसरे चरण में दी गई ज़रूरी शर्तें पूरी हो गई हैं.

अगर जांच पूरी हो जाती है, तो पीआर बताएगा कि जांच पास हो गई है. मंज़ूरी पा चुके PR को मैन्युअल तरीके से, मिलती-जुलती वेबसाइट के सेट की सूची में मैन्युअल तरीके से एक बार (ईस्टर्न टाइम के मुताबिक मंगलवार रात 12 बजे) में मर्ज कर दिया जाएगा.

अगर किसी भी जांच में गड़बड़ी होती है, तो शिकायत करने वाले को GitHub पर पीआर फ़ेलियर के बारे में सूचना दी जाएगी. शिकायत करने वाला व्यक्ति, गड़बड़ियों को ठीक कर सकता है और पीआर को अपडेट कर सकता है. साथ ही, ध्यान रखें कि:

  • पीआर के फ़ेल होने पर, गड़बड़ी का एक मैसेज इस बारे में ज़्यादा जानकारी देगा कि सबमिशन क्यों नहीं हुआ (उदाहरण).
  • सेट के सबमिशन को कंट्रोल करने वाली सभी तकनीकी जांच, GitHub पर की जाती है. इस वजह से, तकनीकी जांच की वजह से हुए सभी सबमिशन GitHub पर दिखेंगे.

एंटरप्राइज़ की नीतियां

एंटरप्राइज़ उपयोगकर्ताओं की ज़रूरतों को पूरा करने के लिए, Chrome में कुछ एंटरप्राइज़ नीतियां लागू की गई हैं:

  • ऐसे सिस्टम जो मिलती-जुलती वेबसाइट के सेट के साथ इंटिग्रेट नहीं हो पाते वे RelatedWebsiteSetsEnabled नीति का इस्तेमाल करके, Chrome के सभी एंटरप्राइज़ इंस्टेंस में, मिलती-जुलती वेबसाइट के सेट की सुविधा को बंद कर सकते हैं.
  • कुछ एंटरप्राइज़ सिस्टम में, सिर्फ़ इंटरनल साइटें (जैसे कि इंट्रानेट) होती हैं. इन साइटों का डोमेन, मिलती-जुलती वेबसाइट के सेट में मौजूद डोमेन से अलग होता है. अगर इन साइटों को सार्वजनिक तौर पर सार्वजनिक किए बिना, मिलती-जुलती वेबसाइट के सेट में शामिल करना है (क्योंकि डोमेन गोपनीय हो सकता है), तो वे RelatedWebsiteSetsOverrides नीति की मदद से, मिलती-जुलती वेबसाइट के सार्वजनिक सेट की सूची में बदलाव कर सकते हैं या उसे बेहतर बना सकते हैं.

"उपयोगकर्ता का प्रॉम्प्ट" और "उपयोगकर्ता का जेस्चर"

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

अन्य साइटों की कुकी या स्टोरेज ऐक्सेस करना

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

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

सुझाव/राय दें या शिकायत करें

GitHub पर सेट सबमिट करें. साथ ही, Storage Access API और requestStorageAccessFor API के साथ काम करें. इससे, आपको प्रोसेस के साथ-साथ किसी भी तरह की समस्या के बारे में अपना अनुभव शेयर करने का मौका मिलता है.

'मिलती-जुलती वेबसाइट के सेट' से जुड़ी चर्चा में शामिल होने के लिए: