Pro HTTP proxy nabízející základní autentizaci může proxyAuthenticator v OkHttp vrátit požadavek s přihlašovacími údaji. Po již odmítnutém pokusu o autorizaci vracejte null, místo abyste znovu posílali stejnou odpověď:

.proxyAuthenticator { _, response ->
    if (response.request.header("Proxy-Authorization") != null) {
        null
    } else {
        response.request.newBuilder()
            .header("Proxy-Authorization",
                    Credentials.basic(proxyUser, proxyPassword))
            .build()
    }
}

Tento náčrt používá hodnoty účtu z tajné konfigurace aplikace. Pojistka povoluje první pokus a zastavuje opakovaný. Implementuje Basic, nikoli každé schéma, které proxy může inzerovat; před volbou této odpovědi prozkoumejte výzvu.

Pokud konečný výsledek zůstává 407, porovnejte vybranou proxy, inzerované schéma a dokumentovanou identitu účtu. Odmítnuté heslo, nepodporovaná metoda a nesprávný tvar uživatelského jména vyžadují různá opravení. Tyto poznatky a konečný stav uchovávejte v redigované diagnostice.

CONNECT má jiný kontext zpětného volání: OkHttp dokumentuje syntetickou předběžnou výzvu proxy autentizace před otevřením tunelu. S tímto kontextem zacházejte podle API, místo abyste předpokládali, že každé zpětné volání je běžná odpověď cíle.

Samostatný authenticator slouží k autentizaci cílového serveru. Uchovávejte jeho údaje odděleně od přihlášení k proxy; obecný interceptor vkládající heslo proxy do každého odchozího požadavku jej může odeslat ve špatném rozsahu.

Historické zprávy popisují i chyby implementace, včetně zpracování těla odmítnuté odpovědi proxy. Před přiřazením současného selhání staré zprávě zaznamenejte verzi OkHttp a konečnou výměnu. Rozhodnutí o opakování by stále mělo zastavit nezměněný pokus s přihlašovacími údaji, který nemá žádnou užitečnou novou odpověď.

Související články