Базавая проксі-аўтэнтыфікацыя OkHttp: спыніце адхіленыя паўторы

Для 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 і канчатковы абмен перад тым, як прыпісваць бягучую няўдачу старому паведамленню. Рашэнне аб паўторы павінна ўсё яшчэ спыняць нязменную спробу ўліковых даных, якая не мае карыснага новага адказу.