HTTP 407 ili 401: koja prijava ne uspijeva?
Razlikujte autentifikaciju proxyja i web stranice, pregledajte prava zaglavlja i ne šaljite podatke za prijavu pogrešnoj strani.
407 traži autentifikaciju na proxyju. 401 je traži za ciljni resurs. Jedan zahtjev može susresti oba odgovora, pa prije davanja lozinke utvrdite ko je traži.
Uporedite status i zaglavlja autentifikacijskog izazova
| Odgovor | Zaglavlje izazova | Zaglavlje podataka za prijavu | Uključena strana |
|---|---|---|---|
| 407 Proxy Authentication Required | Proxy-Authenticate | Proxy-Authorization | Posrednički proxy |
| 401 Unauthorized | WWW-Authenticate | Authorization | Tok autentifikacije izvornog resursa |
Status je važan prvi trag, ali pregledajte cijelu razmjenu. Broj 407 u tekstu stranice nije pravi HTTP 407 odgovor. Isto tako, prilagođena prijavna stranica može vratiti 200 i još tražiti autentifikaciju na nivou aplikacije.
Zašto HTTPS može zakazati s 407 prije dolaska do web stranice
Kada obični HTTP proxy prenosi HTTPS zahtjev, klijent uglavnom prvo traži CONNECT tunel. Proxy može tražiti autentifikaciju za taj CONNECT zahtjev. Ako nije završena, TLS sesija s odredištem kroz tunel još nije uspostavljena. Promjena API tokena web stranice zato vjerovatno neće popraviti tu fazu.
Detaljnim izlazom zahtjeva pogledajte gdje se pojavljuje izazov:
curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/Zamijenite lokalno sučelje za osluškivanje svojim i pročitajte prvi izazov u dnevniku. 407 tokom CONNECT-a dolazi prije TLS-a odredišta; kasniji 401 može uslijediti nakon uspješne uspostave tunela.
Podatke proxyja predajte kroz interfejs za proxy
Za krajnju tačku i račun pouzdanog administratora curl može dogovoriti shemu autentifikacije proxyja i zatražiti lozinku koja nije navedena:
curl --proxy http://proxy.example:8080 --proxy-anyauth --proxy-user alice https://example.com/Zamijenite primjer krajnje tačke i korisnika podacima usluge koju smijete koristiti. Navođenje samo korisnika izbjegava lozinku direktno u gornjoj naredbi. Metode zavise od izgradnje curl-a i proxyja; ako dogovaranje ne uspije, provjerite stvarni izazov i mogućnosti izgradnje.
Opcija autentifikacije proxyja odvojena je od curl-ove korisničke autentifikacije izvornog servera. Ne dodajte zaglavlje Authorization za izvor umjesto odgovora na izazov proxyja. Također ne prosljeđujte ručno zaglavlja s podacima proxyja nepovezanim zahtjevima i ne čuvajte ih u zaglavljima koja se ponovo koriste u cijeloj aplikaciji.
Ako proxy i dalje vraća 407
- Potvrdite da koristite predviđeni host i port proxyja.
- Provjerite sheme koje proxy objavljuje umjesto da pretpostavite Basic.
- Potvrdite stanje računa i poseban format korisničkog imena koji usluga možda traži.
- Provjerite prosljeđivanje posebnih znakova ako su podaci u URL-u.
- Utvrdite treba li poslovna autentifikacija integrirana s preglednikom podršku izvršnog okruženja ili platforme.
- Ako dokazi klijenta nisu dovoljni, tražite od administratora identifikator zahtjeva ili serverski zapis očišćen 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 podataka za prijavu proxyja
Autentifikacija proxyja može se desiti prije TLS-a odredišta. Ako je veza sa samim proxyjem nešifrirana, a metoda na njoj otkriva ponovo upotrebljive podatke, HTTPS odredište ne štiti prethodnu razmjenu naknadno. Odaberite usluzi prikladne prijenos i autentifikaciju; ne šaljite privatne račune nepoznatom javnom proxyju.
Prije dijeljenja pregledajte detaljne dnevnike. I kada alat prikriva uobičajena polja za prijavu, mogu ostati korisnici, nazivi internih krajnjih tačaka, kolačići ili drugi identifikacijski podaci.