Uwierzytelnianie Basic proxy w OkHttp: zatrzymaj odrzucane ponowienia

Dla serwera proxy HTTP oferującego uwierzytelnianie Basic proxyAuthenticator w OkHttp może zwrócić żądanie z poświadczeniami. Zwracaj null po tym, jak próba autoryzacji została już odrzucona, zamiast wysyłać ponownie tę samą odpowiedź:

.proxyAuthenticator { _, response ->
    if (response.request.header("Proxy-Authorization") != null) {
        null
    } else {
        response.request.newBuilder()
            .header("Proxy-Authorization",
                    Credentials.basic(proxyUser, proxyPassword))
            .build()
    }
}

Ten szkic używa wartości konta z tajnej konfiguracji aplikacji. Zabezpieczenie pozwala na pierwszą próbę i zatrzymuje powtórzoną. Implementuje Basic, a nie każdy schemat, który może ogłosić proxy; zbadaj wyzwanie przed wybraniem tej odpowiedzi.

Jeśli końcowy wynik nadal wynosi 407, porównaj wybrany serwer proxy, ogłoszony schemat i udokumentowaną tożsamość konta. Odrzucone hasło, nieobsługiwana metoda i nieprawidłowa forma nazwy użytkownika wymagają różnych poprawek. Zachowaj te obserwacje i końcowy stan w zredagowanej diagnostyce.

CONNECT ma inny kontekst wywołania zwrotnego: OkHttp dokumentuje syntetyczne wyzwanie prewencyjnego uwierzytelniania proxy przed otwarciem tunelu. Obsłuż ten kontekst zgodnie z API, zamiast zakładać, że każde wywołanie to zwykła odpowiedź celu.

Oddzielny authenticator służy do uwierzytelniania serwera docelowego. Trzymaj jego poświadczenia oddzielnie od logowania do proxy; ogólny interceptor wstawiający hasło proxy do każdego wychodzącego żądania może wysłać je w niewłaściwym zakresie.

Historyczne raporty opisują też błędy implementacji, w tym obsługę treści odrzuconej odpowiedzi proxy. Zapisz wersję OkHttp i ostatnią wymianę, zanim przypiszesz bieżącą awarię do starego raportu. Decyzja o ponowieniu nadal powinna zatrzymać niezmienioną próbę poświadczeń, która nie ma żadnej użytecznej nowej odpowiedzi.