OkHttp बेसिक प्रॉक्सी प्रमाणीकरण: अस्वीकृत पुनःप्रयास रोकें

बेसिक प्रमाणीकरण देने वाले 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 संस्करण और अंतिम आदान-प्रदान दर्ज करें। पुनःप्रयास निर्णय को अभी भी ऐसा अपरिवर्तित क्रेडेंशियल प्रयास रोकना चाहिए जिसके पास कोई उपयोगी नया उत्तर नहीं है।