प्रॉम्प्ट और लागू संदर्भ
HTTP 511 का अर्थ है कि नेटवर्क एक्सेस प्राप्त करने से पहले क्लाइंट को प्रमाणित होना आवश्यक है। यह आम तौर पर एक इंटरसेप्टिंग प्रॉक्सी या कैप्टिव पोर्टल से आता है, न कि लक्षित ओरिजिन (target origin) से। एक बैकएंड इंजीनियर को यह स्थापित करना चाहिए कि क्या अनुरोध ओरिजिन तक पहुंचा है, बजाय इसके कि वह प्रवेश-नेटवर्क की समस्या को एप्लिकेशन-प्रमाणीकरण विफलता के रूप में गलत समझे।
इंटरव्यूअर क्या मूल्यांकन करता है
- यह समझाना कि एक इंटरसेप्टिंग प्रॉक्सी 511 जनरेट करता है।
- नेटवर्क प्रमाणीकरण, ओरिजिन प्रमाणीकरण और प्रॉक्सी प्रमाणीकरण को अलग करना।
- यह जानना कि 511 प्रतिक्रियाओं (responses) को कैश नहीं किया जाना चाहिए और लॉगिन UI को ओरिजिन पेज के रूप में प्रस्तुत नहीं करना चाहिए।
- रीडायरेक्ट्स का आँख बंद करके पालन करने के बजाय गैर-ब्राउज़र क्लाइंट्स के लिए सुरक्षित हैंडलिंग डिज़ाइन करना।
- प्रॉक्सी, DNS, TLS और अनुरोध लॉग्स के साथ विफलता के स्थान को साबित करना।
उत्तर देने से पहले स्पष्ट करने वाले प्रश्न
- क्या कॉलर एक ब्राउज़र, मोबाइल ऐप या हेडलेस सर्विस क्लाइंट है? पोर्टल को संभालने की उनकी क्षमता भिन्न होती है।
- क्या 511 किसी एंटरप्राइज़ प्रॉक्सी, सार्वजनिक वाई-फाई पोर्टल या एप्लिकेशन गेटवे से आता है? भेजने वाला सीमा को परिभाषित करता है।
- क्या अनुरोध HTTP है या HTTPS? इंटरसेप्टेड TLS पहले प्रमाणपत्र त्रुटि (certificate error) के साथ विफल हो सकता है।
- क्या क्लाइंट लॉगिन संसाधन खोल सकता है और नेटवर्क सत्र बनाए रख सकता है? यदि नहीं, तो वह केवल उपयोगकर्ता से नेटवर्क बदलने के लिए कह सकता है।
- क्या हम किसी रुक-रुक कर होने वाली प्रॉक्सी खराबी का निदान कर रहे हैं या कैप्टिव पोर्टल को एकीकृत कर रहे हैं? एकीकरण के लिए एक सत्र प्रोटोकॉल की भी आवश्यकता होती है।
30-सेकंड उत्तर ढांचा
"511 नेटवर्क-प्रवेश प्रमाणीकरण है, न कि ओरिजिन उपयोगकर्ता लॉगिन। RFC 6585 अनुशंसा करता है कि एक इंटरसेप्टिंग प्रॉक्सी इसे जनरेट करे, एक लॉगिन-संसाधन लिंक प्रदान करे, और प्रतिक्रिया को कैश करने से बचे। मैं यह सत्यापित करने के लिए अंतिम प्रतिक्रिया IP, प्रॉक्सी मार्कर्स और TLS स्थिति रिकॉर्ड करता हूँ कि क्या ओरिजिन ने अनुरोध देखा था; एक ब्राउज़र उपयोगकर्ता को पोर्टल पर निर्देशित कर सकता है, जबकि एक सर्विस क्लाइंट को 511 को 401 के रूप में नहीं मानना चाहिए या किसी अज्ञात मध्यस्थ को व्यावसायिक क्रेडेंशियल्स सबमिट नहीं करना चाहिए। फिर मैं 401 ओरिजिन प्रमाणीकरण को 407 प्रॉक्सी प्रमाणीकरण से अलग करता हूँ और एक नेटवर्क, प्रॉक्सी या क्लाइंट समाधान चुनता हूँ।"
चरण-दर-चरण विस्तृत विश्लेषण
चरण 1: प्रतिक्रिया निर्माता का पता लगाएं। लक्षित DNS पते, TCP पीयर, Via या प्रॉक्सी हेडर, ओरिजिन एक्सेस लॉग्स और गेटवे ट्रेस की तुलना करें। यदि ओरिजिन में कोई मेल खाता अनुरोध नहीं है, तो संभवतः किसी मध्यस्थ ने 511 उत्पन्न किया है।
चरण 2: प्रोटोकॉल सिमेंटिक्स की व्याख्या करें। 511 क्लाइंट को बताता है कि नेटवर्क अभी खुला नहीं है। प्रतिनिधित्व क्रेडेंशियल्स या शर्तों से लिंक हो सकता है, लेकिन इसे पोर्टल फॉर्म को मूल रूप से अनुरोधित ओरिजिन की सामग्री के रूप में प्रस्तुत नहीं करना चाहिए।
चरण 3: पड़ोसी कोड्स को अलग करें। 401 एक ओरिजिन है जो संसाधन प्रमाणीकरण मांग रहा है और आमतौर पर WWW-Authenticate का उपयोग करता है; 407 एक फॉरवर्ड प्रॉक्सी है जो प्रॉक्सी क्रेडेंशियल्स मांग रहा है और Proxy-Authenticate का उपयोग करता है; 511 स्वयं नेटवर्क तक पहुंच से संबंधित है।
चरण 4: क्लाइंट व्यवहार को परिभाषित करें। एक ब्राउज़र नेटवर्क-लॉगिन प्रॉम्प्ट दिखा सकता है। एक API क्लाइंट को एक स्पष्ट नेटवर्क-अनुपलब्ध स्थिति की रिपोर्ट करनी चाहिए, पोर्टल URL रिकॉर्ड करना चाहिए, और उपयोगकर्ता या नेटवर्क व्यवस्थापक की प्रतीक्षा करनी चाहिए। इसे किसी अज्ञात मध्यस्थ को चुपचाप व्यावसायिक क्रेडेंशियल्स सबमिट नहीं करना चाहिए।
चरण 5: HTTPS और कैशिंग को संभालें। HTTPS को इंटरसेप्ट करने से प्रमाणपत्र बेमेल हो सकता है; प्रमाणपत्र सत्यापन को अक्षम करना कोई समाधान नहीं है। एक 511 प्रतिक्रिया को कैश नहीं किया जाना चाहिए, अन्यथा एक अस्थायी नेटवर्क गेट उन क्लाइंट्स तक लीक हो सकता है जो पहले ही प्रमाणित हो चुके हैं।
चरण 6: नैदानिक साक्ष्य बनाएं। उसी नेटवर्क पर, एक HTTP जांच (probe) की व्यावसायिक अनुरोध के साथ तुलना करें और समय, प्रॉक्सी, DNS, प्रमाणपत्र श्रृंखला, स्थिति और ओरिजिन लॉग्स रिकॉर्ड करें। Microsoft Learn प्रॉक्सी कनेक्टिविटी जांच में 511 को संभावित परिणाम के रूप में भी सूचीबद्ध करता है।
चरण 7: विकल्प और सीमाएं बताएं। एंटरप्राइज़ API को व्यावसायिक API के अंदर 511 लॉगिन लागू करने के बजाय प्रॉक्सी अनुमत सूचियों (allowlists), सेवा-खाता इग्रेस, या नेटवर्क प्रमाणीकरण को ठीक करना चाहिए। सार्वजनिक नेटवर्क को एक उपयोगकर्ता द्वारा पूरा करने योग्य पोर्टल प्रवाह और एक टाइमआउट संदेश की आवश्यकता होती है।
मॉडल उत्तर
"मैं पहले 511 को एक नेटवर्क-प्रवेश प्रतिक्रिया के रूप में वर्गीकृत करता हूँ: एक इंटरसेप्टिंग प्रॉक्सी कहता है कि क्लाइंट को नेटवर्क को प्रमाणित करना होगा, और ओरिजिन ने आमतौर पर अनुरोध कभी देखा ही नहीं। यह 401 संसाधन प्रमाणीकरण और 407 प्रॉक्सी-क्रेडेंशियल प्रमाणीकरण से भिन्न है। निर्माता को खोजने के लिए मैं DNS, TCP पीयर, प्रॉक्सी हेडर, TLS प्रमाणपत्र, ओरिजिन लॉग्स और ट्रेस की तुलना करता हूँ। एक ब्राउज़र पोर्टल लिंक खोल सकता है; एक हेडलेस API क्लाइंट को इसे 401 के रूप में पुनः प्रयास नहीं करना चाहिए या किसी अज्ञात प्रॉक्सी को व्यावसायिक क्रेडेंशियल्स नहीं भेजना चाहिए। प्रतिक्रिया को कैश नहीं किया जाना चाहिए, और HTTPS इंटरसेप्शन के कारण होने वाली प्रमाणपत्र त्रुटि को सत्यापन छोड़ कर हल नहीं किया जा सकता है।"
सामान्य गलतियाँ
- 511 को 401 के रूप में मानना → एक ओरिजिन टोकन को रीफ्रेश करने से अनुरोध नेटवर्क से बाहर नहीं जा सकता → पहले प्रतिक्रिया निर्माता का पता लगाएं।
- 511 को 407 के रूप में मानना → पोर्टल सत्र को अनदेखा करते हुए प्रॉक्सी क्रेडेंशियल्स कॉन्फ़िगर करना → नेटवर्क प्रवेश को फॉरवर्ड-प्रॉक्सी प्रमाणीकरण से अलग करें।
- अज्ञात लॉगिन लिंक का स्वचालित रूप से अनुसरण करना → क्रेडेंशियल्स फ़िशिंग पोर्टल पर लीक हो सकते हैं → उत्पत्ति दिखाएं और उपयोगकर्ता को पुष्टि करने दें।
- 511 को कैश करना → प्रमाणित क्लाइंट्स को एक पुराना गेट दिखाई देता रहता है → कैशिंग प्रतिबंधित करें और मध्यस्थों का निरीक्षण करें।
- TLS सत्यापन अक्षम करना → मैन-इन-द-मिडिल जोखिम बढ़ जाता है → नेटवर्क प्रमाणीकरण या विश्वास कॉन्फ़िगरेशन को ठीक करें।
फॉलो-अप प्रश्न और उत्तर
फॉलो-अप 1: ओरिजिन के पास कोई अनुरोध नहीं है, लेकिन क्लाइंट को 511 मिलता है। आगे क्या?
कनेक्शन पीयर, प्रॉक्सी श्रृंखला और प्रतिक्रिया हेडर कैप्चर करें, फिर उसी नेटवर्क पर एक ज्ञात HTTP जांच को क्वेरी करें। यदि कई गंतव्य समान प्रतिक्रिया दिखाते हैं, तो इग्रेस प्रॉक्सी या कैप्टिव पोर्टल का निरीक्षण करें।
फॉलो-अप 2: पोर्टल HTML को API JSON के रूप में क्यों न लौटाएं?
गैर-ब्राउज़र क्लाइंट्स HTML को एक व्यावसायिक प्रतिक्रिया के रूप में पार्स कर सकते हैं और विफल हो सकते हैं; इससे भी बदतर, वे पोर्टल सामग्री को ओरिजिन सामग्री समझ सकते हैं। एक स्पष्ट त्रुटि वर्ग और एक सत्यापन योग्य लॉगिन प्रवेश बिंदु का उपयोग करें।
फॉलो-अप 3: HTTPS अनुरोध अक्सर 511 के बजाय प्रमाणपत्र त्रुटि क्यों दिखाते हैं?
जब कोई मध्यस्थ सुरक्षित रूप से ओरिजिन TLS प्रमाणपत्र को प्रतिस्थापित नहीं कर सकता है, तो HTTP स्थिति मौजूद होने से पहले ही हैंडशेक विफल हो जाता है। क्लाइंट यह नहीं मान सकते कि प्रत्येक नेटवर्क गेट को 511 के रूप में व्यक्त किया जा सकता है।
फॉलो-अप 4: क्या 511 प्राप्त करने के बाद क्लाइंट पुनः प्रयास कर सकता है?
नेटवर्क प्रमाणीकरण और सत्र स्थापना की पुष्टि होने के बाद ही मूल अनुरोध का पुनः प्रयास करें। आँख बंद करके किए गए पुनः प्रयास ट्रैफ़िक को बढ़ाते हैं, और व्यावसायिक राइट्स (writes) को स्वचालित रूप से फिर से नहीं चलाया जाना चाहिए।
फॉलो-अप 5: आप प्रॉक्सी फॉल्स पॉजिटिव को वास्तविक पोर्टल से कैसे अलग करते हैं?
नेटवर्क, डोमेन, प्रॉक्सी सेटिंग्स, ओरिजिन लॉग्स और पोर्टल सत्रों की तुलना करें। यदि केवल एक एंटरप्राइज़ इग्रेस पथ 511 लौटाता है, तो पहले उसकी नीति और अनुमत सूची (allowlist) का निरीक्षण करें।
फॉलो-अप 6: क्या होगा यदि किसी मोबाइल ऐप में कोई ब्राउज़र लॉगिन UI नहीं है?
एक पठनीय नेटवर्क-अनुपलब्ध स्थिति लौटाएं और उपयोगकर्ता को सिस्टम नेटवर्क-लॉगिन पेज या किसी अन्य नेटवर्क पर निर्देशित करें। प्रमाणीकरण के बाद पुनः कनेक्ट करें; एम्बेडेड पेज में अज्ञात नेटवर्क क्रेडेंशियल्स चुपचाप सबमिट न करें।
फॉलो-अप 7: 511 को कैश क्यों नहीं किया जाना चाहिए?
नेटवर्क प्रमाणीकरण अस्थायी और क्लाइंट-विशिष्ट होता है। कैशिंग किसी अन्य क्लाइंट को वही गेट दिखा सकती है और पहले से अधिकृत उपयोगकर्ता को अवरुद्ध रख सकती है।