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

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

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

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

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

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

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

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

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

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

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

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

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

Storage Access API

Browser Support

  • Chrome: 119.
  • Edge: 85.
  • Firefox: 65.
  • Safari: 11.1.

Source

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

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

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

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

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

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

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

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

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

Chrome में requestStorageAccessFor

Browser Support

  • Chrome: 119.
  • Edge: 119.
  • Firefox: not supported.
  • Safari: not supported.

Source

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

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

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

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

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

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

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

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 और rSAFor अनुदान को अलग-अलग अनुमतियों के तौर पर माना जाता है.

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

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

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

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

सुरक्षा

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

अनुरोधों में 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 को चालू करना होगा. इसके बाद, कमांड-लाइन से Chrome को --use-related-website-set फ़्लैग के साथ लॉन्च करें. साथ ही, उस 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. अपने RWS की पहचान करना

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

2. आरडब्ल्यूएस सबमिशन बनाएं

GitHub रिपॉज़िटरी की स्थानीय कॉपी (क्लोन या फ़ोर्क) बनाएं. अपने सेट को दिखाने के लिए, नई शाखा में related_website_sets.JSON फ़ाइल में बदलाव करें. यह पक्का करने के लिए कि आपके सेट में सही JSON फ़ॉर्मैटिंग और स्ट्रक्चर है, JSON जनरेटर टूल का इस्तेमाल किया जा सकता है.

3. पक्का करें कि आपका आरडब्ल्यूएस, तकनीकी ज़रूरी शर्तों को पूरा करता हो

पक्का करें कि सेट बनाने की ज़रूरी शर्तें और सेट की पुष्टि करने की ज़रूरी शर्तें पूरी की गई हों.

4. अपने आरडब्ल्यूएस को स्थानीय तौर पर टेस्ट करना

अपना सेट सबमिट करने के लिए, पुल रिक्वेस्ट (पीआर) बनाने से पहले, अपने सबमिशन की स्थानीय तौर पर जांच करें, ताकि यह पक्का किया जा सके कि वह सभी ज़रूरी जांचों में पास हो.

5. अपना आरडब्ल्यूएस सबमिट करना

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

पीआर बनाने के बाद, कई तरह की जांच की जाती हैं. इससे यह पक्का किया जाता है कि तीसरे चरण की ज़रूरी शर्तें पूरी की गई हैं. जैसे, आपने सीएलए पर हस्ताक्षर किए हैं और .well-known फ़ाइल मान्य है.

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

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

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

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

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

Chrome, सार्वजनिक और एंटरप्राइज़ सेट के इंटरसेक्शन को दो में से किसी एक तरीके से हल करता है. यह इस बात पर निर्भर करता है कि replacemements या additions में से किसका इस्तेमाल किया गया है.

उदाहरण के लिए, सार्वजनिक सेट {primary: A, associated: [B, C]} के लिए:

replacements सेट: {primary: C, associated: [D, E]}
एंटरप्राइज़ सेट, नया सेट बनाने के लिए सामान्य साइट को शामिल करता है.
नतीजे के तौर पर मिलने वाले सेट: {primary: A, associated: [B]}
{primary: C, associated: [D, E]}
additions सेट: {primary: C, associated: [D, E]}
सार्वजनिक और एंटरप्राइज़ सेट को आपस में जोड़ दिया जाता है.
नतीजा: {primary: C, associated: [A, B, D, E]}

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

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

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

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

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

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

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

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