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 गंतव्य आधीच्या देवाणघेवाणीला नंतर संरक्षण देत नाही. सेवेसाठी योग्य ट्रान्सपोर्ट आणि प्रमाणीकरण निवडा; अनोळखी सार्वजनिक प्रॉक्सीला खासगी खाती पाठवू नका.
तपशीलवार लॉग शेअर करण्याआधी पाहा. नेहमीची लॉगइन क्षेत्रे लपवली तरी वापरकर्तानावे, अंतर्गत एंडपॉइंट नावे, कुकी किंवा इतर ओळख दर्शवणारी माहिती उरू शकते.