Основна прокси автентикација со OkHttp: запрете одбиени повторувања
Користете proxyAuthenticator на OkHttp за прокси предизвици и запрете го повторувањето на непроменет обид за авторизација.
За HTTP прокси што нуди основна автентикација, proxyAuthenticator на OkHttp може да врати барање со акредитиви. Вратете null откако обидот за авторизација веќе е одбиен, наместо повторно да го испратите истиот одговор:
.proxyAuthenticator { _, response ->
if (response.request.header("Proxy-Authorization") != null) {
null
} else {
response.request.newBuilder()
.header("Proxy-Authorization",
Credentials.basic(proxyUser, proxyPassword))
.build()
}
}
Оваа скица користи вредности на сметката од тајната конфигурација на апликацијата. Заштитата дозволува прв обид и го запира повторениот. Таа имплементира Basic, не секоја шема што проксито може да ја објави; проверете го предизвикот пред да го изберете тој одговор.
Ако конечниот резултат остане 407, споредете го избраното прокси, објавената шема и документираниот идентитет на сметката. Одбиена лозинка, неподдржан метод и погрешен облик на корисничко име бараат различни исправки. Чувајте ги тие набљудувања и конечниот статус во редигирана дијагностика.
CONNECT има друг контекст на повратен повик: OkHttp документира синтетички превентивен предизвик за прокси автентикација пред отворањето на тунелот. Ракувајте со тој контекст според API, наместо да претпоставувате дека секој повратен повик е обичен одговор на дестинација.
Одделниот authenticator е за автентикација на серверот дестинација. Чувајте ги неговите акредитиви одделно од прокси најавата; општ интерцептор што става прокси лозинка на секое излезно барање може да ја испрати во погрешен опсег.
Историските извештаи опишуваат и грешки во имплементацијата, вклучително ракување со телото на одбиен прокси одговор. Забележете ја верзијата на OkHttp и конечната размена пред да ја припишете тековната грешка на стар извештај. Одлуката за повторување сепак треба да го запре непроменетиот обид со акредитиви што нема корисен нов одговор.