HTTP 407 eller 401: kva innlogging sviktar?
Skil proxyautentisering frå autentiseringa til nettstaden, undersøk rette hovud og unngå å sende påloggingsopplysningar til feil ledd.
Eit 407 ber deg autentisere deg hos proxyen. Eit 401 ber om autentisering for målressursen. Éin førespurnad kan møte begge, så avklar kven som spør før du gjev eit passord.
Samanlikn status og autentiseringshovud
| Svar | Hovud med autentiseringsutfordring | Hovud med påloggingsopplysningar | Part det gjeld |
|---|---|---|---|
| 407 Proxy Authentication Required | Proxy-Authenticate | Proxy-Authorization | Ein mellomliggjande proxy |
| 401 Unauthorized | WWW-Authenticate | Authorization | Autentiseringsflyten til opphavsressursen |
Statusen er eit viktig første spor, men undersøk heile utvekslinga. Ei side som viser talet 407 i teksten, er ikkje eit faktisk HTTP 407-svar. Ei eiga innloggingsside kan òg returnere 200 og likevel krevje autentisering på applikasjonsnivå.
Kvifor HTTPS kan svikte med 407 før nettstaden vert nådd
Når ein vanleg HTTP-proxy fraktar ein HTTPS-førespurnad, ber klienten som regel først om ein CONNECT-tunnel. Proxyen kan krevje autentisering for denne CONNECT-førespurnaden. Dersom ho ikkje vert fullført, er TLS-økta med målet enno ikkje oppretta gjennom tunnelen. Å endre API-tokenet til nettstaden vil difor neppe reparere dette steget.
Bruk ein førespurnad med detaljert utdata for å sjå kvar autentiseringskravet kjem:
curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/Byt ut det lokale lyttepunktet med ditt og les det første kravet i loggen. Eit 407 under CONNECT kjem før mål-TLS; eit seinare 401 kan følgje etter at tunnelen er oppretta.
Gje proxyopplysningar gjennom proxygrensesnittet
For eit endepunkt og ein konto frå ein administrator du stolar på, kan curl forhandle autentiseringsmetoden og spørje etter eit manglande passord:
curl --proxy http://proxy.example:8080 --proxy-anyauth --proxy-user alice https://example.com/Byt dømeendepunktet og brukarnamnet med opplysningane til tenesta du har lov til å bruke. Berre å gje brukarnamnet unngår passordet direkte i kommandoen ovanfor. Støtta metodar varierer med curl-bygget og proxyen; sjekk den faktiske utfordringa og funksjonane til bygget dersom forhandlinga sviktar.
Valet for proxyautentisering er skilt frå curl si brukarautentisering mot opphavsserveren. Ikkje legg til eit Authorization-hovud for opphavet som erstatning for svaret på proxyutfordringa. Unngå òg å vidaresende hovud med proxyopplysningar til uvedkomande førespurnader eller lagre dei i hovud som vert brukte om att av heile applikasjonen.
Dersom proxyen held fram med å returnere 407
- Kontroller at du brukar rett proxyvert og port.
- Sjekk metodane proxyen annonserer i staden for å føresetje Basic.
- Stadfest kontostatus og eventuelle krav til formatet på brukarnamnet.
- Sjekk korleis spesialteikn vert overførte dersom opplysningane ligg i ein URL.
- Avklar om nettlesarintegrert bedriftsautentisering treng støtte frå køyremiljøet eller plattforma.
- Be administratoren om ein førespurnads-ID eller tenarloggpost reinska for sensitive opplysningar når klientbevisa ikkje strekk til.
Eit 403 eller avvist CONNECT kan skuldast tilgangsreglar sjølv etter vellukka innlogging. Fleire passordforsøk gjev ikkje tilgang til eit forbode mål.
HTTPS på målet vernar ikkje all utveksling av proxyopplysningar
Proxyautentisering kan skje før mål-TLS er etablert. Dersom sambandet til sjølve proxyen er ukryptert og metoden eksponerer opplysningar som kan brukast om att der, vernar ikkje eit HTTPS-mål den tidlegare utvekslinga i ettertid. Vel transport og autentisering som passar tenesta, og ikkje send private kontoar til ein ukjend offentleg proxy.
Gå gjennom detaljerte loggar før du deler dei. Sjølv om verktøyet maskerer vanlege påloggingsfelt, kan loggen innehalde brukarnamn, interne endepunktnamn, informasjonskapslar eller andre identifiserande data.