Основна прокси аутентификација у OkHttp-у: зауставите одбијена понављања

Користите OkHttp proxyAuthenticator за прокси изазове и зауставите понављање непромењеног покушаја ауторизације.

За HTTP прокси који нуди основну аутентификацију, OkHttp proxyAuthenticator може вратити захтев са акредитивима. Вратите 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-а и коначну размену пре него тренутни неуспех припишете старом извештају. Одлука о понављању и даље треба да заустави непромењен покушај акредитива који нема користан нови одговор.

Повезани чланци