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

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

एजी कितामुरा
आइजी कितामुरा
Twitter GitHub Glitch Mastodon

अपडेट

  • 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 Messages API जैसे अन्य तरीकों का इस्तेमाल करना होगा. हम इस बदलाव को जल्द से जल्द शिप करने के लिए, Chrome 112 को टारगेट कर रहे हैं. हालांकि, यह शिपिंग के इंटेंट से मिलने वाले जवाब पर निर्भर करता है.

अगर आपकी वेबसाइट document.domain के ज़रिए, एक ही ऑरिजिन से जुड़ी नीति में छूट पर निर्भर रहती है, तो साइट को ठीक से काम करने के लिए 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://parent.example.com पर, https://video.example.com के लिए क्रॉस-ऑरिजिन DOM में हेर-फेर करने का विकल्प है.

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

यह एक आसान तकनीक है, लेकिन इससे सुरक्षा का खतरा पैदा हो जाता है.

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

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

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

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

Chrome के प्लान के मुताबिक, Chrome 112 में document.domain को नहीं बदला जा सकेगा.

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

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

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

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

आप अपनी साइट को Lighthouse से काम न करने वाले एपीआई ऑडिट के ज़रिए चलाकर उन सभी एपीआई का पता लगा सकते हैं जिन्हें Chrome से हटाने के लिए शेड्यूल किया गया है.

वैकल्पिक क्रॉस-ऑरिजिन कम्यूनिकेशन

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

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

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

यहां दिए गए उदाहरण में:

  1. https://parent.example.com, DOM में हेरफेर करने के लिए postMessage() के ज़रिए मैसेज भेजकर, iframe में https://video.example.com का अनुरोध करता है.
  2. मैसेज मिलते ही https://video.example.com, DOM में बदलाव करता है और सफलता की सूचना माता-पिता को देता है.
  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 Messages API के साथ काम नहीं करेंगी, तो हमें @ChromiumDev के ज़रिए Twitter पर बताएं या document.domain टैग का इस्तेमाल करके Stack Overflow पर पूछें.

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

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

Origin-Agent-Cluster: ?0

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

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

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

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

वेबसाइट का अलग-अलग ब्राउज़र पर चलना

रिसॉर्स

स्वीकार हैं

Unsplash पर ब्रेडन एंडरसन की फ़ोटो