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 गन्तव्यले पहिलेको आदानप्रदान पछि सुरक्षित बनाउँदैन। सेवाका लागि उपयुक्त ट्रान्सपोर्ट र प्रमाणीकरण छान्नुहोस्; अपरिचित सार्वजनिक प्रोक्सीलाई निजी खाता नपठाउनुहोस्।
विस्तृत लग बाँड्नुअघि हेर्नुहोस्। साधारण लगइन फिल्ड लुकाए पनि प्रयोगकर्ता नाम, भित्री एन्डपोइन्ट नाम, कुकी वा अरू पहिचानयोग्य डेटा बाँकी रहन सक्छ।