HTTP 407 czy 401: które logowanie zawodzi?
Odróżnij uwierzytelnianie proxy od uwierzytelniania witryny, sprawdź właściwe nagłówki i nie wysyłaj danych logowania do złego pośrednika.
407 żąda uwierzytelnienia w proxy. 401 żąda uwierzytelnienia do zasobu docelowego. Jedno żądanie może napotkać oba, więc przed podaniem hasła ustal, kto go wymaga.
Porównaj status i nagłówki wyzwania uwierzytelnienia
| Odpowiedź | Nagłówek wyzwania | Nagłówek danych logowania | Uczestnik |
|---|---|---|---|
| 407 Proxy Authentication Required | Proxy-Authenticate | Proxy-Authorization | Pośredniczące proxy |
| 401 Unauthorized | WWW-Authenticate | Authorization | Proces uwierzytelniania zasobu źródłowego |
Status jest podstawową pierwszą wskazówką, ale przejrzyj całą wymianę. Liczba 407 w tekście strony nie oznacza rzeczywistej odpowiedzi HTTP 407. Podobnie własna strona logowania może zwrócić 200 i nadal wymagać uwierzytelnienia na poziomie aplikacji.
Dlaczego HTTPS może zakończyć się 407 jeszcze przed dotarciem do witryny
Przy przesyłaniu HTTPS przez zwykłe proxy HTTP klient zazwyczaj prosi najpierw o utworzenie tunelu CONNECT. Proxy może zażądać uwierzytelnienia tego żądania CONNECT. Jeśli nie zostanie ono ukończone, sesja TLS z celem przez tunel jeszcze nie istnieje. Zmiana tokenu API witryny raczej nie naprawi więc tego etapu.
Włącz szczegółowy wynik żądania, aby zobaczyć, gdzie pojawia się wyzwanie:
curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/Zastąp lokalny punkt nasłuchu swoim i odczytaj pierwsze wyzwanie w logu. 407 podczas CONNECT występuje przed TLS celu; późniejsze 401 może pojawić się już po udanym utworzeniu tunelu.
Podawaj dane proxy przez interfejs przeznaczony dla proxy
Dla punktu końcowego i konta od zaufanego administratora curl może negocjować schemat uwierzytelniania proxy i poprosić o brakujące hasło:
curl --proxy http://proxy.example:8080 --proxy-anyauth --proxy-user alice https://example.com/Zastąp przykładowy punkt końcowy i użytkownika danymi usługi, do której masz uprawnienia. Podanie tylko użytkownika pozwala uniknąć hasła bezpośrednio w powyższym poleceniu. Metody zależą od kompilacji curl i proxy; gdy negocjacja się nie uda, sprawdź rzeczywiste wyzwanie i możliwości kompilacji.
Opcja uwierzytelniania proxy jest oddzielna od opcji curl dla użytkownika serwera źródłowego. Nie dodawaj nagłówka Authorization dla źródła zamiast odpowiedzi na wyzwanie proxy. Nie przekazuj też ręcznie nagłówków danych proxy do niepowiązanych żądań i nie zapisuj ich w nagłówkach współdzielonych przez całą aplikację.
Jeśli proxy nadal zwraca 407
- Upewnij się, że używasz zamierzonego hosta i portu proxy.
- Sprawdź schematy ogłaszane przez proxy zamiast zakładać Basic.
- Potwierdź stan konta i wymagany przez usługę format użytkownika.
- Sprawdź przekazywanie znaków specjalnych, jeśli dane są osadzone w URL.
- Ustal, czy firmowe logowanie zintegrowane z przeglądarką wymaga wsparcia środowiska wykonawczego lub platformy.
- Gdy dane klienta nie wystarczają, poproś administratora o identyfikator żądania lub wpis logu serwera oczyszczone z danych wrażliwych.
403 albo odmowa CONNECT mogą wynikać z polityki dostępu nawet po udanym logowaniu. Kolejne próby haseł nie otworzą zabronionego celu.
HTTPS celu nie chroni każdej wymiany danych logowania proxy
Uwierzytelnianie proxy może nastąpić przed TLS celu. Jeśli połączenie z samym proxy jest nieszyfrowane, a metoda ujawnia na nim dane wielokrotnego użytku, cel HTTPS nie ochroni tej wymiany wstecznie. Wybierz odpowiedni dla usługi transport i uwierzytelnianie; nie wysyłaj prywatnych kont do nieznanego publicznego proxy.
Przejrzyj szczegółowe logi przed udostępnieniem. Nawet gdy narzędzie ukrywa typowe pola logowania, mogą pozostać nazwy użytkowników, wewnętrzne punkty końcowe, ciasteczka i inne dane identyfikujące.