For en HTTP-proxy som tilbyr Basic-autentisering, kan OkHttps proxyAuthenticator returnere en forespørsel som bærer legitimasjon. Returner null etter at et autorisasjonsforsøk allerede er avvist, i stedet for å sende det samme svaret igjen:

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

Denne skissen bruker kontoverdier fra applikasjonens hemmelige konfigurasjon. Vakten tillater et første forsøk og stopper et gjentatt. Den implementerer Basic, ikke alle opplegg en proxy kan annonsere; undersøk utfordringen før du velger det svaret.

Hvis det endelige resultatet fortsatt er 407, sammenlign den valgte proxyen, det annonserte opplegget og den dokumenterte kontoidentiteten. Et avvist passord, en metode som ikke støttes og en feil brukernavnform krever forskjellige rettelser. Behold disse observasjonene og sluttstatusen i redigerte diagnostikker.

CONNECT har en annen tilbakemeldingskontekst: OkHttp dokumenterer en syntetisk foregripende proxy-autentiseringsutfordring før tunnelen åpnes. Håndter den konteksten i samsvar med API-et i stedet for å anta at hver tilbakemelding er et vanlig destinasjonssvar.

Den separate authenticator er for autentisering mot destinasjonsserveren. Hold legitimasjonen atskilt fra proxy-påloggingen; en generisk interceptor som setter et proxy-passord på hver utgående forespørsel kan sende det i feil omfang.

Historiske rapporter beskriver også implementeringsfeil, inkludert håndtering av avviste proxy-svarslegemer. Registrer OkHttp-versjonen og den siste utvekslingen før du tilskriver en nåværende feil en gammel rapport. Gjentakelsesbeslutningen bør fortsatt stoppe et uforandret legitimasjonsforsøk som ikke har noe nyttig nytt svar.

Relaterte artikler