Pentru un proxy HTTP care oferă autentificare Basic, proxyAuthenticator din OkHttp poate returna o cerere care transportă acreditări. Returnați null după ce o încercare de autorizare a fost deja respinsă, în loc să trimiteți din nou același răspuns:

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

Această schiță folosește valori de cont din configurația secretă a aplicației. Protecția permite o încercare inițială și oprește una repetată. Implementează Basic, nu fiecare schemă pe care un proxy o poate anunța; examinați provocarea înainte de a alege acel răspuns.

Dacă rezultatul final rămâne 407, comparați proxy-ul selectat, schema anunțată și identitatea de cont documentată. O parolă respinsă, o metodă neacceptată și o formă greșită a numelui de utilizator necesită corecții diferite. Păstrați aceste observații și starea finală în diagnostice redactate.

CONNECT are un alt context de apel invers: OkHttp documentează o provocare sintetică de autentificare proxy preventivă înainte de deschiderea tunelului. Tratați acel context conform API-ului în loc să presupuneți că fiecare apel invers este un răspuns obișnuit de destinație.

authenticator separat este pentru autentificarea la serverul de destinație. Păstrați acreditările sale separate de autentificarea proxy; un interceptor generic care pune o parolă proxy pe fiecare cerere ieșită o poate trimite în domeniul greșit.

Rapoartele istorice descriu și erori de implementare, inclusiv tratarea corpului unui răspuns proxy respins. Înregistrați versiunea OkHttp și schimbul final înainte de a atribui o eroare actuală unui raport vechi. Decizia de reîncercare ar trebui să oprească în continuare o încercare neschimbată de acreditări care nu are niciun răspuns nou util.

Articole similare