За 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 и конечната размена пред да ја припишете тековната грешка на стар извештај. Одлуката за повторување сепак треба да го запре непроменетиот обид со акредитиви што нема корисен нов одговор.

Поврзани статии