एक ही ऑरिजिन से जुड़ी नीति में छूट देने के लिए, Chrome document.domain में बदलाव करने की सुविधा बंद कर देगा

अगर आपकी वेबसाइट document.domain सेटिंग पर निर्भर है, तो आपको कार्रवाई करनी होगी.

Eiji Kitamura

अपडेट

  • 30 मई, 2023: हमने एलान किया है कि document.domain सेटर की सुविधा, Chrome 115 में काम नहीं करेगी.
  • 7 अप्रैल, 2023: Chrome 112 में इस बदलाव को शामिल करने से पहले, हमें एक समस्या का पता चला है. document.domain सेट करने वाले को डिफ़ॉल्ट रूप से हटा दिया जाएगा. फ़िलहाल, इसे निलंबित कर दिया गया है. साथ ही, शिपिंग के लिए नया माइलस्टोन तय नहीं किया गया है. कृपया इस ब्लॉग पोस्ट पर वापस आएं या blink-dev और इस थ्रेड की सदस्यता लें.
  • 20 जनवरी, 2023: अपडेट की गई टाइमलाइन—document.domain सेटर को Chrome 112 से डिफ़ॉल्ट रूप से हटा दिया जाएगा. साथ ही, document.domain के व्यवहार को कंट्रोल करने के लिए, एंटरप्राइज़ नीति के बारे में जानकारी जोड़ी गई है.
  • 25 जुलाई, 2022: अपडेट की गई टाइमलाइन—document.domain सेटर को Chrome 109 से डिफ़ॉल्ट रूप से हटा दिया जाएगा.
  • 4 फ़रवरी, 2022: नई टाइमलाइन के साथ अपडेट किया गया - हम Chrome 100 से शुरू होने वाले समस्याओं वाले पैनल में चेतावनी दिखाएंगे. साथ ही, Chrome 106 से डिफ़ॉल्ट रूप से document.domain सेटर को हटा देंगे.
पर जाएं

document.domain को ऑरिजिन का होस्टनेम पाने या सेट करने के लिए डिज़ाइन किया गया था.

Chrome पर, वेबसाइटें document.domain सेट नहीं कर पाएंगी. क्रॉस-ऑरिजिन से कम्यूनिकेट करने के लिए, आपको postMessage() या Channel Messaging API जैसे अन्य तरीकों का इस्तेमाल करना होगा. हम इस बदलाव को जल्द से जल्द Chrome 112 में उपलब्ध कराने के लिए काम कर रहे हैं. हालांकि, यह शिप करने के इंटेंट के जवाब पर निर्भर करता है.

अगर आपकी वेबसाइट सही तरीके से काम करने के लिए, document.domain के ज़रिए एक ही ऑरिजिन की नीति में छूट पर निर्भर करती है, तो साइट को Origin-Agent-Cluster: ?0 हेडर भेजना होगा. साथ ही, उन सभी दस्तावेज़ों को भी Origin-Agent-Cluster: ?0 हेडर भेजना होगा जिनके लिए ऐसा करना ज़रूरी है. ध्यान दें कि अगर सिर्फ़ एक दस्तावेज़ इसे सेट करता है, तो document.domain का कोई असर नहीं पड़ता.

document.domain को अपरिवर्तनीय क्यों बनाया जाए?

कई वेबसाइटें document.domain को सेट करती हैं, ताकि एक ही साइट के क्रॉस-ऑरिजिन पेजों के बीच कम्यूनिकेशन की अनुमति मिल सके.

इसका इस्तेमाल करने का तरीका यहां बताया गया है:

मान लें कि https://parent.example.com पर मौजूद कोई पेज, https://video.example.com से iframe पेज को एम्बेड करता है. इन पेजों का eTLD+1 (example.com) एक ही है, लेकिन सबडोमेन अलग-अलग हैं. जब दोनों पेजों का document.domain, 'example.com' पर सेट होता है, तो ब्राउज़र दोनों ऑरिजिन को एक ही ऑरिजिन मानता है.

https://parent.example.com के लिए document.domain सेट करें:

// Confirm the current origin of "parent.example.com"
console.log(document.domain);

// Set the document.domain
document.domain = 'example.com';
console.log(document.domain);

https://video.example.com के लिए document.domain सेट करें:

// Confirm the current origin of "video.example.com"
console.log(document.domain);

// Set the document.domain
document.domain = 'example.com';
console.log(document.domain);

अब https://video.example.com के ख़िलाफ़, https://parent.example.com पर क्रॉस-ऑरिजिन डीओएम मैनिपुलेशन बनाया जा सकता है.

वेबसाइटें document.domain सेट करती हैं, ताकि एक ही साइट के दस्तावेज़ों के बीच आसानी से जानकारी शेयर की जा सके. इस बदलाव की वजह से, एक ही ऑरिजिन से जुड़ी नीति में ढील मिलती है. इसलिए, पैरंट पेज, iframe के दस्तावेज़ को ऐक्सेस कर सकता है और डीओएम ट्री को ट्रैवर्स कर सकता है. इसके अलावा, iframe भी पैरंट पेज के दस्तावेज़ को ऐक्सेस कर सकता है और डीओएम ट्री को ट्रैवर्स कर सकता है.

यह एक आसान तरीका है. हालांकि, इससे सुरक्षा से जुड़ा जोखिम भी होता है.

document.domain से जुड़ी सुरक्षा से जुड़ी समस्याएं

document.domain से जुड़ी सुरक्षा से जुड़ी समस्याओं की वजह से, स्पेसिफ़िकेशन में बदलाव किया गया है. इसमें उपयोगकर्ताओं को इस सुविधा का इस्तेमाल करने से बचने के लिए चेतावनी दी गई है. अन्य ब्राउज़र वेंडर के साथ चल रही मौजूदा बातचीत भी इसी दिशा में आगे बढ़ रही है.

उदाहरण के लिए, जब दो पेज document.domain सेट करते हैं, तो वे ऐसा दिखा सकते हैं कि वे एक ही ऑरिजिन के हैं. यह खास तौर पर तब ज़रूरी होता है, जब ये पेज अलग-अलग सबडोमेन के साथ, शेयर की गई होस्टिंग सेवा का इस्तेमाल करते हैं. document.domain सेटिंग से, उसी सेवा की होस्ट की गई सभी अन्य साइटों का ऐक्सेस मिल जाता है. इससे, हमलावर आपकी साइटों को आसानी से ऐक्सेस कर पाते हैं. ऐसा इसलिए हो सकता है, क्योंकि document.domain, डोमेन के पोर्ट नंबर वाले हिस्से को अनदेखा करता है.

document.domain सेट करने से सुरक्षा पर पड़ने वाले असर के बारे में ज़्यादा जानने के लिए, MDN पर"Document.domain" पेज पढ़ें.

Chrome 112 में, document.domain को बदले नहीं जा सकने वाला बनाने की योजना है.

मुझे कैसे पता चलेगा कि मेरी साइट पर असर पड़ा है या नहीं?

अगर इस बदलाव का असर आपकी वेबसाइट पर पड़ता है, तो Chrome, DevTools के 'समस्याएं' पैनल में चेतावनी देगा. सबसे ऊपर दाएं कोने में मौजूद, पीले रंग के फ़्लैग पर ध्यान दें.

document.domain में बदलाव करने पर, समस्याओं वाले पैनल में एक चेतावनी दिखती है.
document.domain में बदलाव करने पर, समस्याओं वाले पैनल में चेतावनी दिखती है.

अगर आपने रिपोर्टिंग एंडपॉइंट सेट अप किया है, तो आपको एपीआई या सुविधा के बंद होने की रिपोर्ट भी भेजी जाएंगी. रिपोर्ट इकट्ठा करने वाली मौजूदा सेवाओं या अपना समाधान बनाकर, Reporting API का इस्तेमाल करने के तरीके के बारे में ज़्यादा जानें.

LightHouse के ऐसे एपीआई का ऑडिट करके, अपनी साइट की जांच की जा सकती है जिन्हें Chrome से हटाने के लिए शेड्यूल किया गया है.

क्रॉस-ऑरिजिन कम्यूनिकेशन का अन्य तरीका

फ़िलहाल, अपनी वेबसाइट के लिए document.domain को बदलने के तीन विकल्प हैं.

postMessage() या Channel Messaging API का इस्तेमाल करना

ज़्यादातर मामलों में, क्रॉस-ऑरिजिन postMessage() या Channel Messaging API का इस्तेमाल करके, document.domain की जगह ली जा सकती है.

नीचे दिए गए उदाहरण में:

  1. https://parent.example.com, postMessage() के ज़रिए मैसेज भेजकर, डीओएम में बदलाव करने के लिए, https://video.example.com से अनुरोध करता है.
  2. https://video.example.com मैसेज मिलने के तुरंत बाद, डीओएम में बदलाव करता है और पैरंट को सूचना देता है.
  3. https://parent.example.com इस बात की पुष्टि करता है.

https://parent.example.com पर:

// Send a message to https://video.example.com
iframe.postMessage('Request DOM manipulation', 'https://video.example.com');

// Receive messages
iframe.addEventListener('message', (event) => {
  // Reject all messages except ones from https://video.example.com
  if (event.origin !== 'https://video.example.com') return;

  // Filter success messages
  if (event.data === 'succeeded') {
    // DOM manipulation is succeeded
  }
});

https://video.example.com पर:

// Receive messages
window.addEventListener('message', (event) => {
  // Reject all messages except ones from https://parent.example.com
  if (event.origin !== 'https://parent.example.com') return;

  // Do a DOM manipulation on https://video.example.com.

  // Send a success message to https://parent.example.com
  event.source.postMessage('succeeded', event.origin);
});

इसे आज़माकर देखें कि यह कैसे काम करती है. अगर आपके पास ऐसी खास ज़रूरतें हैं जो postMessage() या Channel Messaging API के साथ काम नहीं करेंगी, तो हमें Twitter पर @ChromiumDev के ज़रिए बताएं या document.domain टैग के साथ Stack Overflow पर पूछें.

आखिरी विकल्प के तौर पर, Origin-Agent-Cluster: ?0 हेडर भेजें

अगर आपके पास document.domain सेट करना जारी रखने की कोई खास वजह है, तो टारगेट किए गए दस्तावेज़ के साथ Origin-Agent-Cluster: ?0 रिस्पॉन्स हेडर भेजा जा सकता है.

Origin-Agent-Cluster: ?0

Origin-Agent-Cluster हेडर, ब्राउज़र को निर्देश देता है कि दस्तावेज़ को ऑरिजिन के हिसाब से बने एजेंट क्लस्टर से मैनेज किया जाना चाहिए या नहीं. Origin-Agent-Cluster के बारे में ज़्यादा जानने के लिए, Origin-Agent-Cluster हेडर की मदद से परफ़ॉर्मेंस को अलग करने का अनुरोध करना लेख पढ़ें.

यह हेडर भेजने पर, आपका दस्तावेज़ डिफ़ॉल्ट रूप से बदलाव न किए जाने की स्थिति में होने के बाद भी document.domain सेट करना जारी रख सकता है.

एंटरप्राइज़ नीति के लिए OriginAgentClusterDefaultEnabled को कॉन्फ़िगर करना

आपका एडमिन, OriginAgentClusterDefaultEnabled नीति को false पर कॉन्फ़िगर कर सकता है, ताकि आपके पूरे संगठन में Chrome इंस्टेंस पर document.domain को डिफ़ॉल्ट रूप से सेट किया जा सके. ज़्यादा जानने के लिए, Chrome Enterprise की नीति की सूची और मैनेजमेंट | दस्तावेज़ पढ़ें.

ब्राउज़र के साथ काम करना

संसाधन

आभार

Unsplash पर Braydon Anderson की ओर से अपलोड की गई फ़ोटो