OkHttp baza prokura aŭtentigo: haltigu rifuzitajn ripetojn

Uzu la proxyAuthenticator de OkHttp por prokuraj defioj kaj haltigu ripeton de senŝanĝa rajtiga provo.

Por HTTP-prokuro ofertanta bazan aŭtentigon, la proxyAuthenticator de OkHttp povas redoni peton kun legitimiloj. Redonu null post kiam rajtiga provo jam estis rifuzita, anstataŭ resendi la saman respondon:

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

Ĉi tiu skizo uzas kontajn valorojn el la sekreta agordo de la aplikaĵo. La gardo permesas unuan provon kaj haltigas ripetan. Ĝi realigas Basic, ne ĉiun skemon kiun prokuro povas anonci; ekzamenu la defion antaŭ ol elekti tiun respondon.

Se la fina rezulto restas 407, komparu la elektitan prokuron, la anoncitan skemon kaj la dokumentitan kontan identecon. Rifuzita pasvorto, nesubtenata metodo kaj malĝusta formo de uzantnomo bezonas malsamajn korektojn. Konservu tiujn observojn kaj la finan staton en redaktitaj diagnozoj.

CONNECT havas alian retroalvokan kuntekston: OkHttp dokumentas sintezan anticipecan prokuran aŭtentigan defion antaŭ ol malfermi la tunelon. Traktu tiun kuntekston laŭ la API anstataŭ supozi ke ĉiu retroalvoko estas ordinara celloka respondo.

La aparta authenticator estas por aŭtentigo de la celloka servilo. Tenu ĝiajn legitimilojn aparte de la prokura ensaluto; ĝenerala interkaptilo, kiu metas prokuran pasvorton en ĉiun elirantan peton, povas sendi ĝin en la malĝusta amplekso.

Historiaj raportoj ankaŭ priskribas efektivigajn cimojn, inkluzive de traktado de rifuzita prokura responda korpo. Registru la version de OkHttp kaj la finan interŝanĝon antaŭ ol atribui nunan malsukceson al malnova raporto. La ripeta decido ankoraŭ devus haltigi senŝanĝan legitimilan provon kiu havas neniun utilan novan respondon.

Rilataj artikoloj