HTTP 407 ili 401: koja prijava ne uspijeva?
Razlikujte autentifikaciju proxyja od autentifikacije web-mjesta, provjerite prava zaglavlja i ne šaljite vjerodajnice pogrešnoj strani.
407 traži autentifikaciju na proxyju. 401 je traži za ciljni resurs. Jedan zahtjev može naići na oba odgovora, pa prije unošenja lozinke utvrdite tko je traži.
Usporedite status i zaglavlja zahtjeva za autentifikaciju
| Odgovor | Zaglavlje zahtjeva za autentifikaciju | Zaglavlje vjerodajnica | Uključena strana |
|---|---|---|---|
| 407 Proxy Authentication Required | Proxy-Authenticate | Proxy-Authorization | Posrednički proxy |
| 401 Unauthorized | WWW-Authenticate | Authorization | Tijek autentifikacije izvornog resursa |
Status je važan prvi trag, ali pregledajte cijelu razmjenu. Broj 407 u tekstu stranice nije stvarni odgovor HTTP 407. Isto tako, prilagođena prijavna stranica može vratiti 200 i još zahtijevati autentifikaciju na aplikacijskoj razini.
Zašto HTTPS može zakazati s 407 prije nego što dosegne web-mjesto
Kad obični HTTP proxy prenosi HTTPS zahtjev, klijent obično najprije traži uspostavu tunela CONNECT. Proxy može zatražiti autentifikaciju tog zahtjeva CONNECT. Ako nije dovršena, TLS sesija s odredištem kroz tunel još nije uspostavljena. Promjena API tokena web-mjesta zato vjerojatno neće popraviti taj korak.
Detaljnim izlazom zahtjeva pogledajte gdje se javlja zahtjev za autentifikaciju:
curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/Zamijenite lokalno sučelje za slušanje svojim i pročitajte prvi zahtjev za autentifikaciju u zapisniku. 407 tijekom CONNECT-a dolazi prije TLS-a odredišta; kasniji 401 može uslijediti nakon uspješne uspostave tunela.
Vjerodajnice proxyja predajte kroz sučelje za proxy
Za krajnju točku i račun pouzdanog administratora curl može dogovoriti shemu autentifikacije proxyja i zatražiti nedostajuću lozinku:
curl --proxy http://proxy.example:8080 --proxy-anyauth --proxy-user alice https://example.com/Zamijenite oglednu krajnju točku i korisnika podacima usluge koju smijete koristiti. Navođenje samo korisnika izbjegava lozinku izravno u gornjoj naredbi. Metode ovise o izgradnji curl-a i proxyju; kad pregovaranje ne uspije, provjerite stvarni zahtjev za autentifikaciju i mogućnosti izgradnje.
Opcija autentifikacije proxyja odvojena je od curl-ove korisničke autentifikacije izvornog poslužitelja. Ne dodajte zaglavlje Authorization za izvor umjesto odgovora na zahtjev proxyja. Također ne prosljeđujte ručno zaglavlja s vjerodajnicama proxyja nepovezanim zahtjevima i ne spremajte ih u zaglavlja koja ponovno koristi cijela aplikacija.
Ako proxy stalno vraća 407
- Potvrdite da koristite predviđeni host i priključak proxyja.
- Provjerite sheme koje proxy oglašava umjesto da pretpostavite Basic.
- Potvrdite stanje računa i poseban format korisničkog imena koji usluga možda traži.
- Provjerite prijenos posebnih znakova ako su vjerodajnice u URL-u.
- Utvrdite treba li poslovna autentifikacija integrirana u preglednik podršku izvršnog okruženja ili platforme.
- Ako podaci klijenta nisu dovoljni, od administratora zatražite identifikator zahtjeva ili stavku poslužiteljskog zapisnika očišćenu od osjetljivih podataka.
403 ili odbijen CONNECT može biti odluka pravila pristupa i nakon uspješne prijave. Dodatni pokušaji lozinke neće otvoriti zabranjeno odredište.
HTTPS odredišta ne štiti svaku razmjenu vjerodajnica proxyja
Autentifikacija proxyja može se dogoditi prije TLS-a odredišta. Ako je veza sa samim proxyjem nešifrirana, a metoda na njoj otkriva ponovno uporabljive vjerodajnice, HTTPS odredište ne štiti tu razmjenu naknadno. Odaberite usluzi prikladne prijenos i autentifikaciju te ne šaljite privatne račune nepoznatom javnom proxyju.
Prije dijeljenja pregledajte detaljne zapisnike. I kad alat prikriva uobičajena polja vjerodajnica, u njima mogu ostati korisnici, nazivi internih krajnjih točaka, kolačići ili drugi identifikacijski podaci.