प्रॉम्प्ट और संदर्भ
होटल या एयरपोर्ट नेटवर्क पर यूज़र्स को API से 511 Network Authentication Required प्राप्त होता है। किसी ने इसे बदलकर 401 या 302 कर दिया, जिससे SDK के पुनः प्रयास (retries), कैशिंग और लॉगिन प्रवाह में टकराव होने लगा। 511 की ज़िम्मेदारी की सीमा समझाएं, इसे 401 और 407 से अलग करें, और ब्राउज़र, मोबाइल क्लाइंट और गैर-ब्राउज़र क्लाइंट के लिए सुरक्षित रिकवरी डिज़ाइन करें।
यह प्रश्न सामान्य बैकएंड, नेटवर्किंग और प्लेटफ़ॉर्म साक्षात्कारों के लिए उपयुक्त है। मुख्य बात इंटरसेप्टिंग प्रॉक्सी की पहचान करना है, न कि नेटवर्क एडमिशन को एप्लिकेशन-अकाउंट प्रमाणीकरण के साथ मिलाना।
साक्षात्कारकर्ता क्या परख रहा है
एक सशक्त उत्तर यह बताता है कि 511 सामान्यतः एक इंटरसेप्टिंग प्रॉक्सी द्वारा उत्पन्न किया जाता है जो नेटवर्क एक्सेस को नियंत्रित करती है, और इसका अर्थ है कि क्लाइंट को नेटवर्क एडमिशन पूरा करना होगा। 401 का अर्थ है कि ओरिजिन या सुरक्षित संसाधन को एप्लिकेशन प्रमाणीकरण की आवश्यकता है; 407 का अर्थ है कि प्रॉक्सी को प्रॉक्सी क्रेडेंशियल्स की आवश्यकता है। साथ ही यह भी बताएं कि 511 एप्लिकेशन लॉगिन का प्रमाण नहीं है और API क्लाइंट्स को बिना सोचे-समझे किसी HTML रीडायरेक्ट को JSON नहीं मान लेना चाहिए।
पहले पूछे जाने वाले स्पष्टीकरण प्रश्न
- किस हॉप ने 511 उत्पन्न किया, और क्या क्लाइंट स्थानीय प्रॉक्सी और ओरिजिन के बीच अंतर कर सकता है?
- क्या क्लाइंट एक ब्राउज़र पेज, नेटिव मोबाइल ऐप, CLI या बैकग्राउंड सर्विस है?
- क्या नेटवर्क पोर्टल का कोई स्थिर डिटेक्शन एंडपॉइंट और रिस्पॉन्स प्रोटोकॉल है?
- क्या API अनुरोध दोबारा प्रयास करने योग्य (retryable) है, और क्लाइंट को कैसे पता चलेगा कि नेटवर्क स्वीकृत हो गया है?
- क्या इसमें TLS इंटरसेप्शन, सर्टिफिकेट पिनिंग, प्रॉक्सी क्रेडेंशियल्स, या संवेदनशील सीक्रेट्स शामिल हैं?
30-सेकंड का उत्तर ढांचा
"511 का अर्थ है कि नेटवर्क-एडमिशन लेयर को प्रमाणीकरण की आवश्यकता है और यह आमतौर पर एक इंटरसेप्टिंग प्रॉक्सी द्वारा उत्पन्न होता है। 401 संसाधन प्रमाणीकरण है और 407 प्रॉक्सी प्रमाणीकरण है। मैं 511 को 302 में नहीं बदलूंगा और न ही किसी SDK को पोर्टल HTML को JSON के रूप में पार्स करने दूंगा। एक ब्राउज़र नियंत्रित नेटवर्क-लॉगिन प्रॉम्प्ट दिखा सकता है; गैर-ब्राउज़र क्लाइंट्स को संरचित नेटवर्क स्थिति लौटानी चाहिए, अंधाधुंध पुनः प्रयासों को रोकना चाहिए, और विश्वसनीय पुष्टि के बाद ही मूल अनुरोध दोबारा भेजना चाहिए। एप्लिकेशन क्रेडेंशियल्स को कभी भी किसी अज्ञात पोर्टल पर नहीं भेजा जाना चाहिए।"
चरण-दर-चरण विस्तृत उत्तर
चरण 1: पता लगाएं कि 511 किसने उत्पन्न किया
RFC 6585 उस क्लाइंट के लिए 511 को परिभाषित करता है जिसे नेटवर्क एक्सेस प्राप्त करने के लिए प्रमाणीकरण की आवश्यकता होती है, और MDN बताता है कि यह ओरिजिन के बजाय एक इंटरसेप्टिंग प्रॉक्सी द्वारा उत्पन्न होता है। सामान्य मामलों में सार्वजनिक वाई-फ़ाई की शर्तों को स्वीकार करना, पोर्टल लॉगिन और डिवाइस पंजीकरण शामिल हैं। जहां संभव हो वहां प्रॉक्सी और नेटवर्क संदर्भ को लॉग करें, लेकिन यह न मान लें कि क्लाइंट हमेशा किसी मध्यस्थ की पहचान विश्वसनीय रूप से कर सकते हैं।
चरण 2: 401 में अंतर बताएं
401 का अर्थ है कि अनुरोध में लक्षित संसाधन के लिए मान्य क्रेडेंशियल्स की कमी है, आमतौर पर ओरिजिन WWW-Authenticate चुनौती के साथ। क्लाइंट टोकन को रीफ्रेश कर सकता है या एप्लिकेशन प्रोटोकॉल के अनुसार यूज़र को साइन इन करने के लिए कह सकता है। यह संसाधन-अनुमति की समस्या का वर्णन करता है, न कि ऐसे स्थानीय नेटवर्क का जिसे अभी तक अनुमति नहीं मिली है।
चरण 3: 407 में अंतर बताएं
407 Proxy-Authenticate और Proxy-Authorization का उपयोग करके प्रॉक्सी प्रमाणीकरण की मांग करता है। प्रॉक्सी क्रेडेंशियल्स और एप्लिकेशन-अकाउंट क्रेडेंशियल्स अलग-अलग ट्रस्ट डोमेन हैं। 407 को कभी भी 401 न मानें और न ही यूज़र का एप्लिकेशन पासवर्ड प्रॉक्सी हेडर में डालें; एंटरप्राइज और सार्वजनिक नेटवर्क क्रेडेंशियल स्टोरेज के लिए अलग-अलग नीतियों की आवश्यकता होती है।
चरण 4: सीधे 302 क्यों न लौटाएं?
302 क्लाइंट को दूसरे URL पर निर्देशित करता है। एक ब्राउज़र इसका अनुसरण कर सकता है, लेकिन एक API SDK, वेबहुक उपभोक्ता या कैश पोर्टल HTML को व्यावसायिक प्रतिक्रिया मान सकता है। एक क्रॉस-ओरिजिन पोर्टल अनुरोध संदर्भ को भी उजागर कर सकता है। यदि ब्राउज़र पोर्टल आवश्यक है, तो इसे एक नियंत्रित नेविगेशन प्रवाह में खोलें और पूरा होने के बाद मूल संसाधन का पुनः प्रयास करें, बजाय इसके कि प्रत्येक API प्रतिक्रिया को अप्रत्यक्ष रूप से रीडायरेक्ट कर दिया जाए।
चरण 5: ब्राउज़र हैंडलिंग डिज़ाइन करें
एक ब्राउज़र पोर्टल लिंक और पुनः प्रयास क्रिया के साथ एक स्पष्ट नेटवर्क-लॉगिन प्रॉम्प्ट दिखा सकता है। पोर्टल को एप्लिकेशन पासवर्ड नहीं मांगना चाहिए और न ही किसी अविश्वसनीय प्रॉक्सी को OAuth कॉलबैक टोकन उजागर करना चाहिए। लॉगिन के बाद, एक विश्वसनीय डिटेक्शन अनुरोध के माध्यम से नेटवर्क एक्सेस की पुष्टि करें, फिर मूल पेज को पुनः लोड करें।
चरण 6: गैर-ब्राउज़र हैंडलिंग डिज़ाइन करें
मोबाइल, CLI, और बैकग्राउंड क्लाइंट्स को 511 को पहचानना चाहिए, एडमिशन स्थिति रिकॉर्ड करनी चाहिए, और एक्सपोनेंशियल पुनः प्रयासों को रोकना चाहिए। वे एक विश्वसनीय नेटवर्क-डिटेक्शन इंटरफ़ेस को कॉल कर सकते हैं या सिस्टम नेटवर्क लेयर को सौंप सकते हैं; पुष्टि के बाद, आइडमपोटेंट (idempotent) सेमांटिक्स के साथ अनुरोध पुनः भेजें। गैर-पुनः प्रयास योग्य राइट्स के लिए, पोर्टल प्रक्रिया पूरी न होने तक डुप्लिकेट सबमिशन को रोकें।
चरण 7: TLS और सुरक्षा सीमाओं को संभालें
HTTPS पर, एक इंटरसेप्टिंग प्रॉक्सी सामान्यतः ओरिजिन सामग्री को सुरक्षित रूप से तब तक फ़ॉर्ज नहीं कर सकती जब तक कि डिवाइस या एंटरप्राइज ने एक विश्वसनीय इंटरसेप्शन सर्टिफिकेट इंस्टॉल न किया हो। क्लाइंट्स को "स्वचालित लॉगिन" के लिए सर्टिफिकेट सत्यापन को अक्षम नहीं करना चाहिए। पोर्टल URL, सर्टिफिकेट और रीडायरेक्ट नीतियों के लिए उत्पाद और सुरक्षा समीक्षा आवश्यक है, विशेष रूप से सेशन, भुगतान और प्रशासन API के लिए।
चरण 8: सत्यापित करें, मॉनिटर करें और रिकवर करें
वास्तविक सार्वजनिक नेटवर्क और एक सिम्युलेटेड प्रॉक्सी पर ब्राउज़र, नेटिव क्लाइंट, CLI, बैकग्राउंड जॉब्स, कैश और पुनः प्रयासों का परीक्षण करें। 511 दर, नेटवर्क क्षेत्र, पोर्टल पूर्णता, रिकवरी के बाद पहले अनुरोध की सफलता और डुप्लिकेट राइट्स को ट्रैक करें। सत्यापित करें कि 401 और 407 अभी भी अपने अनुबंधों का पालन करते हैं और 511 को लंबे समय तक रहने वाले त्रुटि पृष्ठ के रूप में कैश नहीं किया जा सकता है।
ट्रेड-ऑफ़ और सीमाएं
511 क्लाइंट को बताता है कि रुकावट ओरिजिन अकाउंट के बजाय नेटवर्क एडमिशन से आती है, लेकिन मध्यस्थ वातावरण हमेशा देखने योग्य या विश्वसनीय नहीं होते हैं। इसे रिकवरी सिग्नल के रूप में समझें, पहचान के प्रमाण के रूप में नहीं। API के लिए, अज्ञात पेज को स्वचालित रूप से खोलने की तुलना में एक स्थिर त्रुटि संरचना और पुनः प्रयासों को रोकना अधिक सुरक्षित है।
प्रत्येक एक्सेस विफलता को 511 पर मैप न करें। ओरिजिन लॉगिन 401 का उपयोग करता है, प्रॉक्सी क्रेडेंशियल्स 407 का उपयोग करते हैं, दर सीमा (rate limiting) 429 का उपयोग करती है, और एक विफल नेटवर्क कनेक्शन कोई भी HTTP प्रतिक्रिया उत्पन्न नहीं कर सकता है। स्टेटस कोड को वास्तविक उत्पन्न करने वाली परत और रिकवरी क्रिया को दर्शाना चाहिए।
रोलआउट योजना और साक्ष्य
पहले एक परीक्षण नेटवर्क में 511 हेडर, बॉडी, कैश व्यवहार और उत्पन्न करने वाले प्रॉक्सी को सत्यापित करें। फिर एक क्लाइंट स्टेट मशीन परिभाषित करें: पता लगाना, प्रॉम्प्ट करना, एडमिशन की प्रतीक्षा करना, पुनः प्रयास करना और विफलता की रिपोर्ट करना। ब्राउज़र एक नियंत्रित पोर्टल का उपयोग करते हैं; गैर-ब्राउज़र क्लाइंट सिस्टम नेटवर्क लेयर या संचालन को सौंपते हैं, कभी भी किसी पेज को एप्लिकेशन क्रेडेंशियल्स नहीं सौंपते हैं।
नेटवर्क, क्लाइंट संस्करण और अनुरोध विधि द्वारा डैशबोर्ड और सैंपल किए गए लॉग बनाएं। राइट्स के लिए आइडमपोटेंसी कुंजियां या स्पष्ट गैर-पुनः प्रयास योग्य अनुबंध जोड़ें; रिकवरी के बाद रीड्स को पुनः प्राप्त करें। जब भी पोर्टल वेंडर या प्रॉक्सी नीति बदलती है, तो संपूर्ण स्वीकृति सुइट चलाएं।
सामान्य गलतियां और फ़ॉलो-अप
511 को 401 समझना
511 नेटवर्क-एडमिशन की समस्या है; 401 संसाधन-प्रमाणीकरण की समस्या है। उनके चुनौती हेडर, क्रेडेंशियल्स और रिकवरी प्रवाह विभिन्न ट्रस्ट डोमेन से संबंधित हैं।
किसी SDK को 302 का स्वतः अनुसरण करने देना
पोर्टल HTML को JSON के रूप में पार्स किया जा सकता है या कैश किया जा सकता है। पहले नेटवर्क स्थिति का पता लगाएं, फिर नियंत्रित प्रवाह में पोर्टल लॉगिन पूरा करें।
पोर्टल को एप्लिकेशन पासवर्ड भेजना
सार्वजनिक-नेटवर्क प्रॉक्सी को एप्लिकेशन क्रेडेंशियल्स प्राप्त नहीं होने चाहिए। पोर्टल नेटवर्क को स्वीकृत करता है; एप्लिकेशन प्रमाणीकरण एक ओरिजिन प्रोटोकॉल बना रहता है।
511 का लगातार पुनः प्रयास करते रहना
एडमिशन से पहले पुनः प्रयास ट्रैफ़िक को बढ़ाते हैं और राइट्स को डुप्लिकेट कर सकते हैं। पुनः प्रयासों को रोकें, विश्वसनीय एडमिशन की प्रतीक्षा करें, और आइडमपोटेंट सेमांटिक्स का उपयोग करें।
आप गैर-ब्राउज़र क्लाइंट्स का परीक्षण कैसे करते हैं?
सिम्युलेटेड और वास्तविक सार्वजनिक नेटवर्क पर CLI, मोबाइल, बैकग्राउंड जॉब्स, कैश और रिकवरी के बाद के रीड्स और राइट्स को कवर करें। 511 पहचान, पुनः प्रयास रोकने, पोर्टल पूर्णता और डुप्लिकेट-सबमिशन मेट्रिक्स की जांच करें।