Базова проксі-автентифікація в 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 і фінальний обмін, перш ніж відносити поточний збій до старого звіту. Рішення про повтор усе одно має зупиняти незмінену спробу облікових даних, яка не має корисної нової відповіді.