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

सम्बन्धित लेखहरू