OkHttp Basic proxy-autentisering: stogge avviste gjentakingar

For ein HTTP-proxy som tilbyr Basic-autentisering, kan proxyAuthenticator i OkHttp returnere ein førespurnad med legitimasjon. Returner null etter at eit autorisasjonsforsøk alt er avvist, i staden for å sende det same svaret på nytt:

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

Denne skissa brukar kontoverdiar frå den hemmelege konfigurasjonen til applikasjonen. Vakta tillét eit første forsøk og stoppar eit gjenteke. Ho implementerer Basic, ikkje kvart opplegg ein proxy kan annonsere; gransk utfordringa før du vel det svaret.

Viss sluttresultatet framleis er 407, samanlikn den valde proxyen, det annonserte opplegget og den dokumenterte kontoidentiteten. Eit avvist passord, ein metode som ikkje er støtta og ei feil brukarnamnform krev ulike rettingar. Ta vare på desse observasjonane og sluttstatusen i redigerte diagnosar.

CONNECT har ein annan tilbakekallingskontekst: OkHttp dokumenterer ei syntetisk førehandsfull proxy-autentiseringsutfordring før tunnelen vert opna. Handter den konteksten etter API-et i staden for å gå ut frå at kvar tilbakekalling er eit vanleg målssvar.

Den separate authenticator er for autentisering mot målstenaren. Hald legitimasjonen hans skild frå proxy-innlogginga; ein generisk interceptor som set eit proxy-passord på kvar utgåande førespurnad kan sende det i feil omfang.

Historiske rapportar skildrar òg implementasjonsfeil, mellom anna handtering av avviste proxy-svarslekamar. Registrer OkHttp-versjonen og den siste utvekslinga før du tillegg ein noverande feil ein gammal rapport. Gjentakingsavgjerda bør framleis stogge eit uendra legitimasjonsforsøk som ikkje har noko nyttig nytt svar.