Prawidłowe hasło u dostawcy nie tworzy pasujących danych uwierzytelniających dla faktycznie wybranego proxy. Zacznij od schematu, hosta i portu tego punktu końcowego; pole hosta zwykle przyjmuje tylko nazwę hosta lub adres IP, a nie pełny URL.

  1. Przeczytaj całą wymianę uwierzytelniania. Jedno 407 po którym następuje zaakceptowana ponowna próba może być normalne. Zanim uznasz logowanie za odrzucone, potwierdź, że wynik końcowy nadal wynosi 407.
  2. Porównaj trasę i zakres danych uwierzytelniających. Dopasuj rzeczywisty host/port i pozostałe pola zdefiniowane przez wdrożony HttpClient 5 AuthScope. Błędny port może pozostawić BasicCredentialsProvider bez odpowiedniego wpisu.
  3. Sprawdź metodę i tożsamość. Czy proxy zaproponowało obsługiwaną metodę? Czy ponowna próba użyła oczekiwanego połączenia? Czy operator wymaga konta kwalifikowanego domenowo lub innego udokumentowanego formatu?

Użyj interfejsu API zainstalowanej wersji głównej. Przepis na pamięć podręczną uwierzytelniania z HttpClient 4 nie przenosi się bez zmian do wersji 5. Korzystaj z wymagań operatora dotyczących konta, zamiast przechodzić przez dowolne warianty nazwy użytkownika.

Uwierzytelnianie wyprzedzające to kolejny świadomy wybór. W przypadku zgodnego schematu może usunąć jedną rundę, ale zmienia moment wysłania danych uwierzytelniających i wymaga obsługiwanego zakresu. Nie może być pierwszą naprawą przy niedopasowanym punkcie końcowym lub nieobsługiwanej metodzie.

Przechowuj zakwestionowaną tożsamość proxy, metodę, zgodność zakresu i stan końcowy w zredagowanych danych diagnostycznych. Hasło i surowe ślady zawierające dane uwierzytelniające nie są potrzebne do tego porównania.

Powiązane artykuły