Chrome 124 में, मिले-जुले कॉन्टेंट को आराम देने के लिए प्राइवेट नेटवर्क ऐक्सेस की अनुमति शामिल है. जिन साइटों को इस बदलाव के लिए तैयार होने के लिए ज़्यादा समय चाहिए उनके लिए, रोक लगाने वाला ट्रायल चल रहा है. हालांकि, यह ट्रायल Chrome 126 के साथ खत्म हो रहा है. इस वर्शन को 4 सितंबर, 2024 को शिप किया जा सकता है. इस पोस्ट में बदलाव के बारे में बताया गया है. साथ ही, सुविधा के डिज़ाइन, मौजूदा वेबसाइटों को माइग्रेट करने, और लागू होने की जांच करने के तरीके के बारे में भी बताया गया है.
क्या बदलाव होने वाले हैं?
यह सुविधा ऐसे डिवाइसों से कनेक्ट करने के लिए fetch() का नया विकल्प उपलब्ध कराती है जो डेवलपर को ऐसे डिवाइस से बात करना है. इसमें नीति के ज़रिए नियंत्रित की जाने वाली एक नई सुविधा शामिल है, जिसकी मदद से हर साइट के लिए इस क्षमता का ऐक्सेस बंद किया जा सकता है. साथ ही, ज़्यादा मेटाडेटा देने के लिए, सर्वर की प्रीफ़्लाइट रिस्पॉन्स के लिए नए हेडर शामिल हैं.
निजी नेटवर्क का ऐक्सेस क्या है?
प्राइवेट नेटवर्क ऐक्सेस (पीएनए) को पहले सीओआरएस-आरएफ़सी1918 और लोकल नेटवर्क ऐक्सेस के नाम से जाना जाता था. यह सुरक्षा से जुड़ी सुविधा है. इसकी मदद से, वेबसाइटों को प्राइवेट नेटवर्क पर सर्वर को अनुरोध भेजने के लिए सीमित किया जाता है. इससे उपयोगकर्ताओं और अंदरूनी नेटवर्क को क्रॉस-साइट अनुरोध जालसाज़ी (सीएसआरएफ़) जैसे संभावित हमलों से बचाने में मदद मिलती है. Chrome में पीएनए को धीरे-धीरे लागू किया जा रहा है. साथ ही, आने वाली रिलीज़ में सुरक्षा को और बढ़ाया जाएगा.
में, पीएनए के बारे में ज़्यादा जानें.अनुमति के अनुरोध की ज़रूरत क्यों होती है?
Chrome 94 ने असुरक्षित सार्वजनिक वेबसाइटों से निजी नेटवर्क के ऐक्सेस को ब्लॉक करने की सुविधा लॉन्च की है. असुरक्षित कॉन्टेक्स्ट से ऐक्सेस के प्राइवेट नेटवर्क को बंद करने के ट्रायल में, प्रभावित वेबसाइटों को एचटीटीपीएस पर माइग्रेट करने में चुनौतियों का पता चला है. एक सामान्य समस्या यह है कि निजी डिवाइसों को एचटीटीपीएस पर माइग्रेट करने में दिक्कत होती है. इस वजह से, मिक्स कॉन्टेंट की जांच से जुड़े उल्लंघन हो सकते हैं.
इस चुनौती से निपटने के लिए, Chrome 120 से ऑरिजिन ट्रायल के तौर पर अनुमति का नया अनुरोध जोड़ा गया. साथ ही, Chrome 124 से स्टेबल वर्शन में अनुमति देने का नया अनुरोध जोड़ा गया.
अनुमति के अनुरोध की ज़रूरत कब पड़ती है?
अनुमति के अनुरोध की सुविधा उपलब्ध होने के बाद, हमने कुछ माइलस्टोन हासिल करने के बाद इस सुविधा को बंद करने की योजना बनाई है. यह पक्का करने के लिए कि आपकी सार्वजनिक वेबसाइटों को एचटीटीपीएस पर माइग्रेट किया जाए, अगर अपने निजी सर्वर को एचटीटीपीएस पर माइग्रेट नहीं किया जा सकता, तो अनुमति के अनुरोध वाली नई सुविधा से, आपको मिक्स कॉन्टेंट की जांच करने की सुविधा नहीं मिलेगी.
अनुमति के अनुरोध के साथ निजी नेटवर्क ऐक्सेस के अनुरोध का सामान्य वर्कफ़्लो इस तरह है.
अनुमति के प्रॉम्प्ट को ट्रिगर करना
नए targetAddressSpace एट्रिब्यूट को, फ़ेच करने के विकल्प के तौर पर जोड़ें. इससे अनुरोध, मिले-जुले कॉन्टेंट की जांच को स्किप कर सकता है.
fetch("http://router.local/ping", {
targetAddressSpace: "private",
});
प्राइवेट नेटवर्क ऐक्सेस: प्रीफ़्लाइट की सुविधा शुरू करने के मुताबिक, किसी भी निजी नेटवर्क के अनुरोध से पहले प्रीफ़्लाइट का अनुरोध किया जाता है. इस प्रीफ़्लाइट अनुरोध में
एक नया हेडर, Access-Control-Request-Private-Network: true शामिल होगा. साथ ही, उससे जुड़े जवाब में
हेडर शामिल होना चाहिए
Access-Control-Allow-Private-Network: true.
नए अनुमति प्रॉम्प्ट को शामिल करने के लिए, डिवाइसों में दो नए रिस्पॉन्स हेडर शामिल होने चाहिए: Private-Network-Access-Name और Private-Network-Access-ID.
Private-Network-Access-ID: कोलन से अलग की गई 48-बिट वैल्यू, जिसे 6 हेक्साडेसिमल बाइट के तौर पर दिखाया जाता है.Private-Network-Access-Name: एक स्ट्रिंग के रूप में एक मान्य नाम जो ECMAScript रेगुलर एक्सप्रेशन से मैच करता है/^[a-z0-9_-.]+$/.नाम की ज़्यादा से ज़्यादा लंबाई 248 UTF-8 कोड यूनिट है.
Private-Network-Access-Name: "My Smart Toothbrush"
Private-Network-Access-ID: "01:23:45:67:89:0A"
डेमो
डेमो देखने के लिए यहां जाएं: https://private-network-access-permission-test.glitch.me/.
डेमो वेबसाइट का इस्तेमाल करने के लिए, आपको अपना निजी निजी सर्वर चालू करना होगा. निजी सर्वर को तय किए गए सर्वर Private-Network-Access-ID और Private-Network-Access-Name के साथ-साथ, एचटीटीपी हेडर Access-Control-Allow-Private-Network: true के साथ जवाब देना चाहिए. अगर
सब कुछ सही तरीके से सेट किया गया है, तो अनुमति का यह अनुरोध दिखना चाहिए:
असुरक्षित कॉन्टेक्स्ट को रोकने के ट्रायल से बाहर निकलें
गैर-सुरक्षित कॉन्टेक्स्ट के लिए प्राइवेट नेटवर्क ऐक्सेस को बंद करने के ट्रायल का रजिस्ट्रेशन करने वाली वेबसाइटों के लिए, यही समय है कि आप अपनी वेबसाइट को अनुमति के हमारे नए अनुरोध के साथ माइग्रेट करें और ट्रायल को बंद करें.
अपना कोड अपडेट करने के बाद, अपने एचटीएमएल, JavaScript या एचटीटीपी हेडर में ट्रायल टोकन को मिटा दें. अगर आपको याद नहीं है कि आपने ट्रायल टोकन कहां रखा है, तो पिछले ब्लॉग पोस्ट में एक्सप्लेनेशन ट्रायल के लिए रजिस्टर करने वाला सेक्शन देखें.
ट्रायल के पेज पर जाकर भी टोकन को मिटाया जा सकता है.
आगे क्या करना है?
गैर-एपीआई fetch() से मिले अनुरोधों के समाधान को अब भी एक्सप्लोर किया जा रहा है.
कई समाधानों की जांच की गई है. उदाहरण के लिए, कॉन्टेंट की सुरक्षा से जुड़ी नई नीति के तौर पर सर्विस वर्कर का इस्तेमाल करना या पते के लिए टारगेट की जाने वाली जगह बनाना. हालांकि, गैर-एपीआई fetch() से मिलने वाले अनुरोधों के आखिरी रूप की जांच अब भी जारी है.
ऐसा हो सकता है कि आने वाले समय में, सब फ़्रेम से किए जाने वाले अनुरोध, अनुमति की नीति के साथ काम करें.
हो सकता है कि आने वाले समय में, हम सब फ़्रेम की सुविधा को आसान बनाने के लिए, अनुमति से जुड़ी नीतियों का समर्थन करना चाहें.
निजी नेटवर्क के इस्तेमाल के उदाहरणों के बारे में सुझाव/राय देना या शिकायत करना
अगर किसी निजी नेटवर्क पर कोई ऐसी वेबसाइट होस्ट की जाती है जिसे सार्वजनिक नेटवर्क से अनुरोध करने की ज़रूरत है, तो Chrome टीम को आपका सुझाव या राय चाहिए! Chromium समस्या ट्रैकर (कॉम्पोनेंट: Blink>SecurityFeature>CORS>privateNetworkAccess) या GitHub रिपॉज़िटरी पर समस्या दर्ज करें.
रिसॉर्स
- प्राइवेट नेटवर्क को ऐक्सेस करने की अनुमति के अनुरोध से जुड़ी खास जानकारी
- प्राइवेट नेटवर्क को ऐक्सेस करने की अनुमति के अनुरोध की जानकारी
- निजी नेटवर्क ऐक्सेस करने के लिए, अलग-अलग तरह की आरामदेह सुविधाओं के बारे में जानें
- प्राइवेट नेटवर्क ऐक्सेस की अनुमति के अनुरोध का ऑरिजिन ट्रायल: एचटीटीपीएस का इस्तेमाल करके, वेबसाइटों को माइग्रेट करने का पाथ