असुरक्षित कॉन्टेक्स्ट के लिए प्राइवेट नेटवर्क ऐक्सेस (पीएनए) को बंद करने का ट्रायल खत्म हो रहा है. पीएनए की अनुमति देने का अनुरोध लागू करें

Yifan Luo
Yifan Luo

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

क्या बदलाव होने वाले हैं?

इस सुविधा की मदद से, निजी नेटवर्क पर ऐसे डिवाइसों से कनेक्ट किया जा सकता है जिनका नाम दुनिया भर में यूनीक नहीं होता. इसलिए, वे TLS सर्टिफ़िकेट नहीं पा सकते. इस सुविधा की मदद से, 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-बिट वैल्यू है, जिसे कोलन से अलग किए गए छह हेक्साडेसिमल बाइट के तौर पर दिखाया जाता है.
  • 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/.

डेमो वेबसाइट का इस्तेमाल करने के लिए, आपको अपना निजी सर्वर शुरू करना होगा. निजी सर्वर को एचटीटीपी हेडर Access-Control-Allow-Private-Network: true के साथ-साथ, सर्वर के तय किए गए हेडर Private-Network-Access-ID और Private-Network-Access-Name के साथ रिस्पॉन्स देना चाहिए. अगर सब कुछ सही तरीके से सेट है, तो अनुमति का यह प्रॉम्प्ट दिखना चाहिए:

असुरक्षित कॉन्टेक्स्ट के इस्तेमाल को बंद करने के ट्रायल से बाहर निकलना

जिन वेबसाइटों ने असुरक्षित कॉन्टेक्स्ट के लिए निजी नेटवर्क ऐक्सेस की सुविधा को बंद करने के ट्रायल के लिए रजिस्टर किया है उनके लिए, अब समय आ गया है कि वे अनुमति के लिए नए प्रॉम्प्ट की मदद से अपनी वेबसाइट को माइग्रेट करें और ट्रायल से बाहर निकलें.

कोड अपडेट करने के बाद, अपने एचटीएमएल, JavaScript या HTTP हेडर में, ट्रायल टोकन मिटाएं. अगर आपको याद नहीं है कि ट्रायल टोकन कहां दिया गया है, तो पिछली ब्लॉग पोस्ट में रजिस्ट्रेशन के लिए उपलब्ध, ट्रायल के लिए रजिस्टर करने की सुविधा से जुड़े सेक्शन पर जाएं.

ट्रायल के पेज पर जाकर भी टोकन को मिटाया जा सकता है.

आगे क्या करना है?

एपीआई के अलावा अन्य तरीकों से किए गए अनुरोधों के लिए, अब भी समाधान ढूंढा जा रहा है.fetch()

कई समाधानों की जांच की गई है. उदाहरण के लिए, सेवा वर्कर का इस्तेमाल करना या टारगेट पते के स्पेस को नई Content-Security-Policy के तौर पर बनाना. हालांकि, एपीआई fetch() के अलावा अन्य तरीकों से किए गए अनुरोधों के लिए, फ़ाइनल स्ट्रक्चर पर अब भी काम किया जा रहा है.

सब-फ़्रेम से आने वाले अनुरोधों के लिए, आने वाले समय में अनुमति की नीति लागू हो सकती है.

आने वाले समय में, हो सकता है कि हम सब-फ़्रेम की सुविधा को कम करने के लिए, अनुमति से जुड़ी नीतियां लागू करना चाहें.

निजी नेटवर्क के इस्तेमाल के उदाहरणों के लिए सुझाव/राय देना या शिकायत करना

अगर आपने किसी निजी नेटवर्क पर ऐसी वेबसाइट होस्ट की है जिसे सार्वजनिक नेटवर्क से अनुरोध चाहिए, तो Chrome की टीम आपसे सुझाव/राय/शिकायत/राय मांगती है! Chromium समस्या ट्रैकर (कॉम्पोनेंट: Blink>SecurityFeature>CORS>PrivateNetworkAccess) या GitHub रिपॉज़िटरी पर समस्या दर्ज करें.

संसाधन