За HTTP прокси, което предлага Basic удостоверяване, 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 и крайния обмен, преди да припишете текущ провал на стар доклад. Решението за повторение все още трябва да спира непроменен опит с идентификационни данни, който няма полезен нов отговор.

Подобни статии