HTTP 407 या 401: कौन-सा लॉगिन विफल हो रहा है?
प्रॉक्सी और वेबसाइट के प्रमाणीकरण में फ़र्क करें, सही हेडर देखें और क्रेडेंशियल गलत पक्ष को भेजने से बचें।
407 प्रॉक्सी पर प्रमाणीकरण माँगता है। 401 गंतव्य संसाधन के लिए प्रमाणीकरण माँगता है। एक अनुरोध को दोनों मिल सकते हैं, इसलिए पासवर्ड देने से पहले पहचानें कि कौन माँग रहा है।
स्टेटस और प्रमाणीकरण चुनौती वाले हेडर की तुलना करें
| उत्तर | चुनौती वाला हेडर | क्रेडेंशियल हेडर | संबंधित पक्ष |
|---|---|---|---|
| 407 Proxy Authentication Required | Proxy-Authenticate | Proxy-Authorization | बीच का प्रॉक्सी |
| 401 Unauthorized | WWW-Authenticate | Authorization | मूल संसाधन का प्रमाणीकरण प्रवाह |
स्टेटस पहली अहम निशानी है, लेकिन पूरा आदान-प्रदान देखें। पेज के पाठ में 407 लिखा होना असली HTTP 407 उत्तर नहीं है। इसी तरह कस्टम लॉगिन पेज 200 लौटाते हुए भी एप्लिकेशन स्तर पर प्रमाणीकरण माँग सकता है।
HTTPS वेबसाइट तक पहुँचने से पहले 407 से क्यों विफल हो सकता है
सामान्य HTTP प्रॉक्सी से HTTPS अनुरोध जाते समय क्लाइंट आम तौर पर पहले CONNECT टनल बनाने को कहता है। प्रॉक्सी उस CONNECT अनुरोध के लिए प्रमाणीकरण माँग सकता है। यह पूरा न हो तो टनल से गंतव्य का TLS सत्र अभी बना ही नहीं है, इसलिए वेबसाइट का API टोकन बदलने से यह चरण ठीक होने की संभावना कम है।
विस्तृत आउटपुट से देखें कि चुनौती कहाँ आती है:
curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/स्थानीय लिसनर की जगह अपना डालें और लॉग की पहली चुनौती पढ़ें। CONNECT के दौरान 407 गंतव्य TLS से पहले आता है; सफल टनल बनने के बाद 401 मिल सकता है।
प्रॉक्सी इंटरफ़ेस से उसके क्रेडेंशियल दें
भरोसेमंद व्यवस्थापक के दिए एंडपॉइंट और खाते के लिए curl प्रॉक्सी प्रमाणीकरण विधि तय कर सकता है और न दिया गया पासवर्ड पूछ सकता है:
curl --proxy http://proxy.example:8080 --proxy-anyauth --proxy-user alice https://example.com/उदाहरण के एंडपॉइंट और उपयोगकर्ता को अधिकृत सेवा के विवरण से बदलें। केवल उपयोगकर्ता देने से ऊपर के कमांड में सीधे पासवर्ड रखना नहीं पड़ता। समर्थित विधियाँ curl बिल्ड और प्रॉक्सी के अनुसार बदल सकती हैं; बातचीत विफल हो तो असली चुनौती और बिल्ड की क्षमता देखें।
प्रॉक्सी प्रमाणीकरण विकल्प curl के मूल सर्वर उपयोगकर्ता प्रमाणीकरण से अलग है। प्रॉक्सी की चुनौती के उत्तर की जगह मूल सर्वर का Authorization हेडर न जोड़ें। प्रॉक्सी क्रेडेंशियल हेडर को असंबंधित अनुरोधों में हाथ से न भेजें और पूरी ऐप में दोबारा इस्तेमाल होने वाले हेडर में न रखें।
प्रॉक्सी लगातार 407 लौटा रहा हो तो
- सही प्रॉक्सी होस्ट और पोर्ट इस्तेमाल होने की पुष्टि करें।
- Basic मान लेने के बजाय प्रॉक्सी की बताई विधियाँ देखें।
- खाते की स्थिति और सेवा के अपेक्षित उपयोगकर्ता नाम प्रारूप की पुष्टि करें।
- क्रेडेंशियल URL में हों तो विशेष अक्षरों के भेजे जाने का तरीका देखें।
- पता करें कि ब्राउज़र से जुड़ा कॉर्पोरेट प्रमाणीकरण रनटाइम या प्लेटफ़ॉर्म समर्थन माँगता है या नहीं।
- क्लाइंट के प्रमाण पर्याप्त न हों तो व्यवस्थापक से संवेदनशील डेटा हटाया हुआ अनुरोध पहचानकर्ता या सर्वर लॉग प्रविष्टि माँगें।
सफल लॉगिन के बाद भी 403 या अस्वीकृत CONNECT पहुँच नीति का निर्णय हो सकता है। और पासवर्ड आज़माने से प्रतिबंधित गंतव्य का अधिकार नहीं मिलेगा।
गंतव्य का HTTPS हर प्रॉक्सी क्रेडेंशियल आदान-प्रदान नहीं बचाता
प्रॉक्सी प्रमाणीकरण गंतव्य TLS बनने से पहले हो सकता है। खुद प्रॉक्सी का कनेक्शन बिना एन्क्रिप्शन हो और विधि उस पर दोबारा इस्तेमाल होने वाले क्रेडेंशियल उजागर करे, तो HTTPS गंतव्य पिछले आदान-प्रदान को बाद में सुरक्षित नहीं बनाता। सेवा के अनुकूल ट्रांसपोर्ट और प्रमाणीकरण चुनें; अनजान सार्वजनिक प्रॉक्सी को निजी खाते न भेजें।
विस्तृत लॉग साझा करने से पहले देखें। सामान्य क्रेडेंशियल फ़ील्ड छिपने पर भी उपयोगकर्ता नाम, आंतरिक एंडपॉइंट नाम, कुकी या पहचान बताने वाला दूसरा डेटा बच सकता है।