HTTP 407 eller 401: hvilken innlogging feiler?
Skill proxyautentisering fra nettstedets autentisering, undersøk riktige headere og unngå å sende påloggingsopplysninger til feil ledd.
Et 407 ber deg autentisere deg hos proxyen. Et 401 ber om autentisering for målressursen. Én forespørsel kan møte begge, så avklar hvem som spør før du oppgir et passord.
Sammenlign status og autentiseringsheadere
| Svar | Header med autentiseringsutfordring | Header med påloggingsopplysninger | Berørt part |
|---|---|---|---|
| 407 Proxy Authentication Required | Proxy-Authenticate | Proxy-Authorization | En mellomliggende proxy |
| 401 Unauthorized | WWW-Authenticate | Authorization | Autentiseringsflyten til opprinnelsesressursen |
Statusen er et viktig første spor, men undersøk hele utvekslingen. En side som viser tallet 407 i teksten, er ikke et faktisk HTTP 407-svar. En egen innloggingsside kan også returnere 200 og likevel kreve autentisering på applikasjonsnivå.
Hvorfor HTTPS kan feile med 407 før nettstedet nås
Når en vanlig HTTP-proxy frakter en HTTPS-forespørsel, ber klienten som regel først om en CONNECT-tunnel. Proxyen kan kreve autentisering for denne CONNECT-forespørselen. Hvis den ikke fullføres, er TLS-økten med målet ennå ikke etablert gjennom tunnelen. Å endre nettstedets API-token vil derfor neppe reparere dette trinnet.
Bruk en forespørsel med detaljert utdata for å se hvor autentiseringskravet oppstår:
curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/Bytt ut det lokale lyttepunktet med ditt og les det første kravet i loggen. Et 407 under CONNECT kommer før mål-TLS; et senere 401 kan følge etter at tunnelen er opprettet.
Gi proxyopplysninger gjennom proxygrensesnittet
For et endepunkt og en konto fra en administrator du stoler på, kan curl forhandle proxyens autentiseringsmetode og spørre etter et manglende passord:
curl --proxy http://proxy.example:8080 --proxy-anyauth --proxy-user alice https://example.com/Bytt eksempelendepunkt og brukernavn med opplysningene for tjenesten du har lov til å bruke. Bare å oppgi brukernavnet unngår passordet direkte i kommandoen ovenfor. Støttede metoder varierer med curl-bygget og proxyen; sjekk den faktiske utfordringen og byggets funksjoner hvis forhandlingen feiler.
Proxyautentiseringens valg er atskilt fra curls brukerautentisering mot opprinnelsesserveren. Ikke legg til en Authorization-header for opprinnelsen som erstatning for et svar på proxyens utfordring. Unngå også manuelt å videresende headere med proxyopplysninger til uvedkommende forespørsler eller lagre dem i headere som gjenbrukes av hele applikasjonen.
Hvis proxyen fortsetter å returnere 407
- Kontroller at du bruker riktig proxyvert og port.
- Sjekk metodene proxyen annonserer i stedet for å forutsette Basic.
- Bekreft kontostatus og eventuelle krav til brukernavnets format.
- Sjekk hvordan spesialtegn overføres dersom opplysningene ligger i en URL.
- Avklar om nettleserintegrert bedriftsautentisering trenger støtte fra kjøremiljøet eller plattformen.
- Be administratoren om en forespørsels-ID eller serverloggpost renset for følsomme opplysninger når klientbevisene ikke er tilstrekkelige.
Et 403 eller avvist CONNECT kan skyldes tilgangsregler selv etter vellykket innlogging. Flere passordforsøk gir ikke tilgang til et forbudt mål.
Målets HTTPS beskytter ikke all utveksling av proxyopplysninger
Proxyautentisering kan skje før mål-TLS er etablert. Hvis forbindelsen til selve proxyen er ukryptert og metoden eksponerer gjenbrukbare opplysninger der, beskytter ikke et HTTPS-mål den tidligere utvekslingen i ettertid. Velg transport og autentisering som passer tjenesten, og ikke send private kontoer til en ukjent offentlig proxy.
Gå gjennom detaljerte logger før du deler dem. Selv når verktøyet maskerer vanlige påloggingsfelt, kan loggen inneholde brukernavn, interne endepunktnavn, informasjonskapsler eller andre identifiserende data.