बैकएंड इंटरव्यू: आप एक प्रॉक्सी चेन में HTTP 407 को कैसे संभालते हैं?

प्रॉम्प्ट और दायरा

एक सर्विस क्लाइंट कई स्पष्ट (explicit) प्रॉक्सी के माध्यम से एक बाहरी API तक पहुँचता है। कुछ अनुरोध 407 लौटाते हैं और अन्य 401 लौटाते हैं। उनके बीच की सीमा, हॉप-बाय-हॉप प्रॉक्सी चुनौतियाँ (challenges), CONNECT टनल, क्रेडेंशियल स्टोरेज, पुनः प्रयास (retries) और ऑब्ज़र्वेबिलिटी की व्याख्या करें।

यह बैकएंड नेटवर्किंग और सुरक्षा से संबंधित प्रश्न है। प्रॉक्सी की संख्या और विफलता दर अभ्यास के लिए की गई धारणाएँ हैं, कोई बाज़ार के दावे नहीं।

इंटरव्यूअर क्या जांच रहा है

• क्या आप रिसोर्स-सर्वर प्रमाणीकरण को अगले-हॉप प्रॉक्सी प्रमाणीकरण से अलग करते हैं।
• क्या आप समझाते हैं कि Proxy-Authenticate और Proxy-Authorization कहाँ उपभोग (consume) किए जाते हैं।
• क्या आप एकाधिक हॉप्स, CONNECT, कनेक्शन पूल और क्रेडेंशियल रोटेशन को संभालते हैं।
• क्या प्रॉक्सी क्रेडेंशियल ऑरिजिन और लॉग्स से दूर रहते हैं।

पूछने के लिए स्पष्टीकरण संबंधी प्रश्न

1. क्या क्लाइंट स्पष्ट (explicit) या पारदर्शी (transparent) प्रॉक्सी का उपयोग कर रहा है, और क्या इसमें CONNECT शामिल है?
2. प्रत्येक प्रॉक्सी किस स्कीम का उपयोग करती है, और क्या कनेक्शन पुनः उपयोग किए जाते हैं?
3. क्या क्लाइंट और गेटवे मूल 401 और 407 हेडर को सुरक्षित रख सकते हैं?
4. क्या अनुरोध एक सुरक्षित रीड (read) है या यह स्थिति (state) को बनाता, चार्ज करता या बदलता है?
5. क्रेडेंशियल को कौन रोटेट करता है, और क्या कोई बैकअप इग्रेस उपलब्ध है?

एक 30-सेकंड का उत्तर

"407 अगले-हॉप प्रॉक्सी की ओर से एक चुनौती है; 401 लक्षित संसाधन (target resource) की ओर से है। मैं हॉप और अनुरोध पहचानकर्ताओं को रिकॉर्ड करता हूँ, Proxy-Authenticate को पढ़ता हूँ, और संबंधित Proxy-Authorization केवल उसी प्रॉक्सी को भेजता हूँ। अगला इनबाउंड प्रॉक्सी इसे उपभोग करता है; इसे ऑरिजिन तक नहीं पहुँचना चाहिए। CONNECT के लिए, टनल बनाने से पहले प्रॉक्सी को प्रमाणित करें, फिर टनल-स्तरीय 401 को ऑरिजिन प्रमाणीकरण के रूप में संभालें। मैं केवल रीप्ले-सुरक्षित अनुरोधों का ही पुनः प्रयास करता हूँ और प्रॉक्सी, स्कीम और क्रेडेंशियल संस्करण द्वारा 407 को मापता हूँ।"

चरण-दर-चरण डिज़ाइन

1. 401 और 407 को अलग करें

401 में WWW-Authenticate लक्षित-संसाधन चुनौती का वर्णन करता है, जिसका उत्तर आमतौर पर Authorization के साथ दिया जाता है। 407 में Proxy-Authenticate अगले-हॉप प्रॉक्सी से मिली चुनौती का वर्णन करता है, जिसका उत्तर Proxy-Authorization के साथ दिया जाता है। समान स्थिति संख्याएँ साझा कैश या एकल त्रुटि हैंडलर को उचित नहीं ठहराती हैं।

2. एक समय में एक हॉप को प्रमाणित करें

प्रत्येक प्रॉक्सी केवल वही क्रेडेंशियल प्राप्त करती है जिनका उसने अनुरोध किया था। RFC 9110 अगले इनबाउंड प्रॉक्सी के लिए Proxy-Authorization को परिभाषित करता है जिसने इसकी मांग की थी; एक श्रृंखला (chain) में, क्रेडेंशियल की अपेक्षा करने वाली पहली प्रॉक्सी इस फ़ील्ड का उपभोग करती है। क्लाइंट प्रॉक्सी या कनेक्शन द्वारा क्रेडेंशियल को अलग करता है और कभी भी प्रॉक्सी हेडर को ऑरिजिन पर अग्रेषित नहीं करता है।

GET https://api.example/report HTTP/1.1
Host: api.example
Proxy-Authorization: Basic <proxy-credential>

3. CONNECT टनल को संभालें

HTTPS लक्ष्य के लिए, क्लाइंट पहले प्रॉक्सी को CONNECT भेजता है। प्रॉक्सी प्रमाणीकरण सफल होने और प्रॉक्सी द्वारा 2xx लौटाए जाने के बाद, क्लाइंट TLS टनल बनाता है। इसके अंदर के अनुरोध ऑरिजिन के होते हैं; एक ऑरिजिन 401 Authorization का उपयोग करता है और इसे प्रॉक्सी 407 समझने की भूल नहीं की जाती है। विफल हुई प्रॉक्सी चुनौती अभी भी CONNECT हॉप से संबंधित होती है।

4. पूल और क्रेडेंशियल को अलग करें

पूल कुंजी (key) में प्रॉक्सी पता, प्रमाणीकरण स्कीम, टेनेंट और क्रेडेंशियल संस्करण शामिल होते हैं। रोटेशन के दौरान, पुराने कनेक्शनों का पुनः उपयोग करना बंद करें या प्रॉक्सी की आवश्यकता के अनुसार पुन: प्रमाणित करें। Proxy-Authorization को क्रॉस-रिक्वेस्ट हेडर टेम्पलेट में न डालें या ट्रेसिंग सिस्टम में इसके मान को रिकॉर्ड न करें।

5. पुनः प्रयासों और साइड इफेक्ट्स को सीमित करें

407 के बाद, केवल तभी पुनः प्रयास करें जब कोई अपरिवर्तनीय बॉडी न भेजी गई हो या ऑपरेशन सुरक्षित रूप से दोबारा चलाने योग्य (replayable) हो। POST, चार्जिंग, या संसाधन निर्माण के लिए, एक व्यावसायिक आइडम्पोटेंसी कुंजी का उपयोग करें और जांचें कि क्या सर्वर ने पहले ही प्रयास को संसाधित कर लिया है। चुनौती प्रबंधन, क्रेडेंशियल रीफ्रेश और रीप्ले अवलोकनीय (observable) घटनाएं होनी चाहिए, न कि एक असीमित लूप।

6. निदान और सुरक्षा के लिए उपकरण तैयार करें (Instrument)

प्रत्येक हॉप के लिए प्रॉक्सी पहचान, CONNECT चरण, स्कीम, क्रेडेंशियल संस्करण, 407 गणना, पुनः प्रयास परिणाम और अंतिम स्थिति रिकॉर्ड करें; केवल संशोधित (redacted) सारांश रखें। लक्ष्य, प्रॉक्सी-नीति, या रोटेशन दोषों का पता लगाने के लिए 401, 407, TLS विफलताओं, पूल पुनः उपयोग और बैकअप-इग्रेस स्विच की तुलना करें। यह साबित करने के लिए विफलताएं इंजेक्ट करें कि कोई मध्यस्थ ऑरिजिन ऑथराइजेशन हेडर को लीक या फिर से लिख नहीं सकता है।

मॉडल उच्च-गुणवत्ता वाला उत्तर

"मैं पथ को प्रॉक्सी और संसाधन परतों में विभाजित करता हूँ। अगली प्रॉक्सी 407 के साथ चुनौती देती है और ऑरिजिन 401 के साथ चुनौती देता है, जो क्रमशः Proxy-Authorization और Authorization का उपयोग करते हैं। क्रेडेंशियल को प्रॉक्सी पहचान द्वारा अलग किया जाता है; प्रॉक्सी फ़ील्ड की अपेक्षा करने वाली पहली इनबाउंड प्रॉक्सी इसका उपभोग करती है, और यह कभी भी ऑरिजिन तक नहीं पहुँचती है। HTTPS टनल ट्रैफ़िक से पहले CONNECT के दौरान प्रॉक्सी को प्रमाणित करता है। पूल प्रॉक्सी और क्रेडेंशियल संस्करण द्वारा अलग किए जाते हैं, और रोटेशन पुराने कनेक्शनों को रिटायर कर देता है। 407 के बाद केवल सुरक्षित अनुरोधों को ही दोबारा चलाया जाता है; साइड इफेक्ट्स आइडम्पोटेंसी और स्टेटस प्रश्नों के साथ ठीक होते हैं। हॉप-स्तरीय मेट्रिक्स दोष की पहचान करते हैं।"

सामान्य गलतियाँ

• 407 को 401 के रूप में मानना → क्रेडेंशियल गलत सीमा पार करते हैं → प्रॉक्सी और संसाधन चुनौतियों को अलग-अलग संभालें।
• प्रॉक्सी क्रेडेंशियल को ऑरिजिन पर अग्रेषित करना → सीक्रेट्स लीक होते हैं → अगली इनबाउंड प्रॉक्सी को उनका उपभोग करने और हटाने दें।
• CONNECT सफल होने से पहले टनल ट्रैफ़िक भेजना → प्रोटोकॉल स्थिति गलत हो जाती है → प्रॉक्सी प्रमाणीकरण पूरा करें और पहले 2xx CONNECT प्राप्त करें।
• सभी कनेक्शन ऑथ स्थिति साझा करना → टेनेंट या क्रेडेंशियल संस्करण आपस में मिल जाते हैं → प्रॉक्सी, टेनेंट और संस्करण द्वारा अलग करें।
• 407 का हमेशा पुनः प्रयास करना → दोष और साइड इफेक्ट्स बढ़ जाते हैं → प्रयासों को सीमित करें, रीप्ले सुरक्षा का परीक्षण करें, और स्थिति क्वेरी करें।

फॉलो-अप प्रश्न और उत्तर

क्या मैं कई प्रॉक्सी के लिए कई Proxy-Authorization मान भेज सकता हूँ?

फ़ील्ड को एक सामान्य क्रेडेंशियल सूची के रूप में न मानें। वह भेजें जो वर्तमान इनबाउंड प्रॉक्सी अपेक्षा करती है; इसके द्वारा फ़ील्ड का उपभोग करने के बाद, उस हॉप की स्कीम के अनुसार बाद की चुनौती को संभालें और सत्यापित करें कि कार्यान्वयन सुरक्षित अग्रेषण की अनुमति देता है।

केवल अंतिम 407 से ही निदान क्यों नहीं किया जाता?

गेटवे मध्यवर्ती प्रतिक्रियाओं को फिर से लिख सकते हैं या निगल सकते हैं, और कनेक्शन का पुनः उपयोग चुनौती को गलत अनुरोध से जोड़ सकता है। वास्तविक जारीकर्ता की पहचान करने के लिए हॉप लॉग्स, कनेक्शन पहचानकर्ता और मूल चुनौती को सुरक्षित रखें।

क्या होगा यदि प्रॉक्सी प्रमाणीकरण सफल हो जाता है लेकिन टनल 401 लौटाती है?

प्रॉक्सी प्रमाणीकरण स्थिति बनाए रखें और ऑरिजिन की WWW-Authenticate चुनौती का उत्तर Authorization के साथ दें। प्रॉक्सी क्रेडेंशियल को फिर से सबमिट न करें या संसाधन क्रेडेंशियल को प्रॉक्सी-ऑथ कैश में न रखें।