HTTP 407 eller 401: vilken inloggning misslyckas?
Skilj proxyautentisering från webbplatsens autentisering, granska rätt huvuden och undvik att skicka inloggningsuppgifter till fel part.
Ett 407 begär autentisering hos proxyn. Ett 401 begär autentisering för målresursen. Samma begäran kan möta båda, så ta reda på vem som frågar innan du lämnar ett lösenord.
Jämför status och huvuden för autentiseringsbegäran
| Svar | Huvud för autentiseringsbegäran | Huvud med inloggningsuppgifter | Berörd part |
|---|---|---|---|
| 407 Proxy Authentication Required | Proxy-Authenticate | Proxy-Authorization | En mellanliggande proxy |
| 401 Unauthorized | WWW-Authenticate | Authorization | Ursprungsresursens autentiseringsflöde |
Statusen är en viktig första ledtråd, men granska hela utbytet. En sida som visar talet 407 i texten är inte samma sak som ett faktiskt HTTP 407-svar. På samma sätt kan en egen inloggningssida returnera 200 och ändå kräva autentisering på applikationsnivå.
Varför HTTPS kan misslyckas med 407 innan webbplatsen nås
När en vanlig HTTP-proxy transporterar en HTTPS-begäran ber klienten vanligtvis först om en CONNECT-tunnel. Proxyn kan begära autentisering för CONNECT-begäran. Om den inte slutförs har TLS-sessionen med destinationen genom tunneln ännu inte upprättats. Att byta webbplatsens API-token lär därför inte lösa just det steget.
Använd en begäran med utförlig utdata för att se var autentiseringsbegäran dyker upp:
curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/Byt ut den lokala lyssnaren mot din och läs den första autentiseringsbegäran i loggen. Ett 407 under CONNECT kommer före destinationens TLS; ett senare 401 kan följa efter att tunneln har upprättats.
Lämna proxyuppgifter via proxygränssnittet
För en ändpunkt och ett konto från en betrodd administratör kan curl förhandla proxyns autentiseringsmetod och fråga efter ett saknat lösenord:
curl --proxy http://proxy.example:8080 --proxy-anyauth --proxy-user alice https://example.com/Byt exempeländpunkt och användarnamn mot uppgifterna för tjänsten du har rätt att använda. Genom att bara ange användarnamnet slipper du lägga lösenordet direkt i kommandot ovan. Metoderna kan variera mellan curl-byggen och proxyer; kontrollera den faktiska autentiseringsbegäran och byggets stöd när förhandlingen misslyckas.
Proxyautentiseringens alternativ är skilt från curls användarautentisering mot ursprungsservern. Lägg inte till ett Authorization-huvud för ursprunget som ersättning för svaret på proxyns begäran. Undvik också att manuellt vidarebefordra proxyuppgiftshuvuden till orelaterade anrop eller spara dem i huvuden som återanvänds i hela programmet.
Om proxyn fortsätter att svara med 407
- Kontrollera att du använder avsedd proxyvärd och port.
- Kontrollera metoderna som proxyn annonserar i stället för att förutsätta Basic.
- Kontrollera kontostatus och om tjänsten kräver ett särskilt användarnamnsformat.
- Kontrollera hur specialtecken överförs om uppgifterna finns i en URL.
- Ta reda på om webbläsarintegrerad företagsautentisering behöver stöd från körmiljön eller plattformen.
- Be administratören om ett rensat begärande-ID eller en serverloggpost utan känsliga uppgifter när klientinformationen inte räcker.
Ett 403 eller nekat CONNECT kan vara ett beslut i åtkomstpolicyn även efter lyckad inloggning. Fler lösenordsförsök ger inte tillgång till en förbjuden destination.
Destinationens HTTPS skyddar inte varje utbyte av proxyuppgifter
Proxyautentisering kan ske före destinationens TLS. Om anslutningen till själva proxyn är okrypterad och metoden exponerar återanvändbara uppgifter där, skyddar inte en HTTPS-destination det tidigare utbytet i efterhand. Välj transport och autentisering som passar tjänsten, och skicka inga privata konton till en okänd offentlig proxy.
Granska utförliga loggar före delning. Även när verktyget maskerar vanliga inloggningsfält kan loggen innehålla användarnamn, interna ändpunktsnamn, kakor eller andra identifierande uppgifter.