For en HTTP-proxy, der tilbyder Basic-godkendelse, kan OkHttps proxyAuthenticator returnere en anmodning med legitimationsoplysninger. Returner null, når et godkendelsesforsøg allerede er blevet afvist, i stedet for at sende det samme svar igen:

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

Denne skitse bruger kontoværdier fra applikationens hemmelige konfiguration. Værnet tillader et første forsøg og stopper et gentaget. Det implementerer Basic, ikke enhver ordning, en proxy kan annoncere; undersøg udfordringen, før du vælger det svar.

Hvis det endelige resultat fortsat er 407, skal du sammenligne den valgte proxy, den annoncerede ordning og den dokumenterede kontoidentitet. En afvist adgangskode, en ikke-understøttet metode og en forkert brugernavnsform kræver forskellige rettelser. Bevar disse observationer og den endelige status i redigerede diagnostikker.

CONNECT har en anden callback-kontekst: OkHttp dokumenterer en syntetisk foregribende proxy-godkendelsesudfordring, før tunnelen åbnes. Håndtér den kontekst efter API'et i stedet for at antage, at hvert callback er et almindeligt destinationssvar.

Den separate authenticator er til godkendelse mod destinationsserveren. Hold dens legitimationsoplysninger adskilt fra proxy-login; en generisk interceptor, der placerer en proxy-adgangskode på hver udgående anmodning, kan sende den i det forkerte omfang.

Historiske rapporter beskriver også implementeringsfejl, herunder håndtering af afviste proxy-svarslegemer. Registrer OkHttp-versionen og den endelige udveksling, før en nuværende fejl tilskrives en gammel rapport. Gentagelsesbeslutningen bør stadig stoppe et uændret legitimationsforsøg, der ikke har noget nyttigt nyt svar.

Relaterede artikler