HTTP 407 of 401: welke aanmelding mislukt?

Een 407 vraagt om authenticatie bij de proxy. Een 401 vraagt om authenticatie voor de doelbron. Eén verzoek kan beide tegenkomen, dus bepaal wie erom vraagt voordat je een wachtwoord geeft.

Vergelijk de status en de authenticatieheaders

De status is een belangrijke eerste aanwijzing, maar bekijk de hele uitwisseling. Een pagina met het getal 407 in de tekst is geen echte HTTP 407-respons. Ook kan een eigen inlogpagina status 200 teruggeven en toch authenticatie op applicatieniveau vereisen.

Waarom HTTPS vóór het bereiken van de website al met 407 kan mislukken

Bij een HTTPS-verzoek via een gewone HTTP-proxy vraagt de client doorgaans eerst om een CONNECT-tunnel. De proxy kan voor dat CONNECT-verzoek authenticatie vragen. Zolang die niet is voltooid, bestaat de TLS-sessie met de bestemming via de tunnel nog niet. Een andere API-token voor de website zal deze fase dan waarschijnlijk niet verhelpen.

Gebruik een verzoek met uitgebreide uitvoer om te zien waar de authenticatievraag verschijnt:

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

Vervang het lokale luisteradres door je eigen adres en lees de eerste authenticatievraag in het log. Een 407 tijdens CONNECT komt vóór TLS met de bestemming; na een geslaagde tunnel kan later een 401 volgen.

Geef proxygegevens via de proxy-interface door

Voor een eindpunt en account van een beheerder die je vertrouwt, kan curl het authenticatieschema van de proxy onderhandelen en om een ontbrekend wachtwoord vragen:

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

Vervang het voorbeeldadres en de gebruikersnaam door de gegevens van de dienst die je mag gebruiken. Door alleen een gebruikersnaam op te geven, staat het wachtwoord niet direct in het bovenstaande commando. Ondersteunde methoden verschillen per curl-build en proxy; controleer bij een mislukte onderhandeling de werkelijke authenticatievraag en de mogelijkheden van de build.

De proxy-authenticatieoptie staat los van curls gebruikersauthenticatie voor de oorspronkelijke server. Voeg geen Authorization-header voor die server toe als vervanging voor een antwoord op de proxyvraag. Stuur proxygegevensheaders evenmin handmatig mee naar ongerelateerde verzoeken en bewaar ze niet in headers die de hele applicatie hergebruikt.

Als de proxy 407 blijft teruggeven

• Controleer of je de bedoelde proxyhost en poort gebruikt.
• Controleer de aangeboden authenticatieschema’s in plaats van Basic aan te nemen.
• Controleer de accountstatus en of de dienst een specifieke gebruikersnaamindeling verlangt.
• Controleer de overdracht van speciale tekens als inloggegevens in een URL zijn opgenomen.
• Bepaal of in de browser geïntegreerde bedrijfsaanmelding ondersteuning van de runtime of het platform nodig heeft.
• Vraag de beheerder om een van gevoelige gegevens ontdane verzoek-ID of serverlogregel als bewijs aan de clientkant onvoldoende is.

Een 403 of geweigerde CONNECT kan ook na een geslaagde aanmelding een beslissing van het toegangsbeleid zijn. Meer wachtwoorden proberen geeft geen toegang tot een verboden bestemming.

HTTPS op de bestemming beschermt niet elke uitwisseling van proxygegevens

Proxy-authenticatie kan vóór het opzetten van TLS met de bestemming gebeuren. Als de verbinding met de proxy zelf onversleuteld is en de methode herbruikbare inloggegevens op dat traject blootlegt, beschermt een HTTPS-doel die eerdere uitwisseling niet achteraf. Kies een passend transport en authenticatieopzet voor de dienst. Stuur geen privéaccounts naar een onbekende publieke proxy.

Controleer uitgebreide logs voordat je ze deelt. Ook als een tool gangbare inlogvelden verbergt, kunnen er nog gebruikersnamen, interne eindpuntnamen, cookies of andere identificerende gegevens in staan.