HTTP 407 eller 401: hvilket login fejler?

Et 407 beder dig godkende dig hos proxyen. Et 401 beder om godkendelse til målressourcen. En anmodning kan møde begge, så find ud af, hvem der spørger, før du giver en adgangskode.

Sammenlign status og godkendelsesheadere

Status er et vigtigt første spor, men undersøg hele udvekslingen. En side med tallet 407 i teksten er ikke et faktisk HTTP 407-svar. En tilpasset web-login-side kan ligeledes returnere 200 og stadig kræve godkendelse i applikationslaget.

Hvorfor HTTPS kan fejle med 407, før webstedet nås

Når en almindelig HTTP-proxy bærer en HTTPS-anmodning, beder klienten normalt først om en CONNECT-tunnel. Proxyen kan kræve godkendelse for den CONNECT-anmodning. Er godkendelsen ikke færdig, er destinationens TLS-session endnu ikke etableret gennem tunnelen. At ændre webstedets API-token vil derfor næppe reparere dette trin.

Brug en anmodning med detaljeret output til at se, hvor godkendelseskravet opstår:

curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/

Erstat det lokale lyttepunkt med dit eget og læs det første godkendelseskrav i loggen. Et 407 under CONNECT kommer før destinationens TLS; et senere 401 kan følge efter en vellykket tunneloprettelse.

Giv proxyoplysninger via proxyens grænseflade

For et endepunkt og en konto fra en administrator, du har tillid til, kan curl forhandle proxyens godkendelsesmetode og spørge efter en manglende adgangskode:

curl --proxy http://proxy.example:8080 --proxy-anyauth --proxy-user alice https://example.com/

Erstat eksemplets endepunkt og brugernavn med oplysningerne for den tjeneste, du har lov til at bruge. Kun at angive brugernavnet undgår adgangskoden direkte i kommandoen ovenfor. Understøttede metoder varierer med curl-bygget og proxyen; kontrollér det faktiske krav og byggets funktioner, hvis forhandlingen fejler.

Proxygodkendelsens tilvalg er adskilt fra curls brugergodkendelse hos oprindelsesserveren. Tilføj ikke en Authorization-header til oprindelsen som erstatning for et svar på proxyens udfordring. Undgå også manuelt at videresende proxyoplysningsheadere til uvedkommende anmodninger eller gemme dem i headere, som hele applikationen genbruger.

Hvis proxyen bliver ved med at returnere 407

• Bekræft, at du bruger den tilsigtede proxyvært og port.
• Se de godkendelsesmetoder, proxyen annoncerer, i stedet for at antage Basic.
• Bekræft kontoens status og eventuelle krav til brugernavnets format.
• Kontrollér overførslen af specialtegn, hvis oplysningerne er indlejret i en URL.
• Afgør, om browserintegreret virksomhedsgodkendelse kræver støtte fra kørselsmiljøet eller platformen.
• Bed administratoren om et renset anmodnings-ID eller en serverlogpost uden følsomme oplysninger, hvis klientens beviser ikke rækker.

Et 403 eller afvist CONNECT kan være en adgangspolitisk beslutning, også efter et vellykket login. Flere adgangskodeforsøg giver ikke adgang til en forbudt destination.

Destinationens HTTPS beskytter ikke alle udvekslinger af proxyoplysninger

Proxygodkendelse kan ske, før destinationens TLS etableres. Hvis forbindelsen til selve proxyen er ukrypteret, og metoden blotlægger genanvendelige legitimationsoplysninger der, beskytter en HTTPS-destination ikke udvekslingen med tilbagevirkende kraft. Vælg en passende transport og godkendelsesordning til tjenesten, og send ikke private konti til en ukendt offentlig proxy.

Gennemgå detaljerede logfiler, før du deler dem. Selv når værktøjet maskerer almindelige legitimationsfelter, kan de stadig indeholde brugernavne, interne endepunktsnavne, cookies eller andre identificerende data.