OkHttp बेसिक प्रॉक्सी प्रमाणीकरण: नाकारलेले पुनःप्रयत्न थांबवा
प्रॉक्सी आव्हानांसाठी OkHttp चा proxyAuthenticator वापरा आणि अपरिवर्तित अधिकृतता प्रयत्न पुन्हा करू नका.
बेसिक प्रमाणीकरण देणाऱ्या HTTP प्रॉक्सीसाठी, OkHttp चा proxyAuthenticator क्रेडेन्शियल्स घेऊन जाणारी विनंती परत करू शकतो. अधिकृतता प्रयत्न आधीच नाकारला गेल्यानंतर तोच उत्तर पुन्हा न पाठवता null परत करा:
.proxyAuthenticator { _, response ->
if (response.request.header("Proxy-Authorization") != null) {
null
} else {
response.request.newBuilder()
.header("Proxy-Authorization",
Credentials.basic(proxyUser, proxyPassword))
.build()
}
}
ही रूपरेषा ॲप्लिकेशनच्या गुप्त कॉन्फिगरेशनमधील खाते मूल्ये वापरते. गार्ड पहिल्या प्रयत्नास परवानगी देतो आणि पुनरावृत्ती थांबवतो. ते Basic लागू करते, प्रॉक्सी जाहीर करू शकते ती प्रत्येक योजना नाही; ते उत्तर निवडण्यापूर्वी आव्हान तपासा.
अंतिम निकाल 407 राहिल्यास, निवडलेला प्रॉक्सी, जाहीर केलेली योजना आणि नोंदवलेली खाते ओळख यांची तुलना करा. नाकारलेला पासवर्ड, असमर्थित पद्धत आणि चुकीचे वापरकर्तानाव स्वरूप यांना वेगवेगळ्या दुरुस्त्या लागतात. ती निरीक्षणे आणि अंतिम स्थिती संपादित निदानात ठेवा.
CONNECT ला दुसरा कॉलबॅक संदर्भ आहे: बोगदा उघडण्यापूर्वी OkHttp कृत्रिम पूर्वपद प्रॉक्सी-प्रमाणीकरण आव्हानाची नोंद करते. प्रत्येक कॉलबॅक सामान्य गंतव्य उत्तर आहे असे गृहीत धरण्याऐवजी तो संदर्भ API नुसार हाताळा.
वेगळा authenticator गंतव्य-सर्व्हर प्रमाणीकरणासाठी आहे. त्याची क्रेडेन्शियल्स प्रॉक्सी लॉगिनपासून वेगळी ठेवा; प्रत्येक बाहेर जाणाऱ्या विनंतीवर प्रॉक्सी पासवर्ड ठेवणारा सामान्य इंटरसेप्टर तो चुकीच्या व्याप्तीत पाठवू शकतो.
ऐतिहासिक अहवाल अंमलबजावणीच्या बग्सचेही वर्णन करतात, त्यात नाकारलेल्या प्रॉक्सी-उत्तराच्या मुख्य भागाची हाताळणी समाविष्ट आहे. सध्याची अयशस्वीता जुन्या अहवालास जोडण्यापूर्वी OkHttp आवृत्ती आणि अंतिम देवाणघेवाण नोंदवा. पुनःप्रयत्नाच्या निर्णयाने उपयुक्त नवीन उत्तर नसलेला अपरिवर्तित क्रेडेन्शियल प्रयत्न थांबवला पाहिजे.