HTTP 407 oder 401: Welche Anmeldung schlägt fehl?
Unterscheiden Sie Proxy- und Website-Authentifizierung, prüfen Sie die richtigen Header und senden Sie Zugangsdaten an die richtige Stelle.
Ein 407 fordert die Authentifizierung beim Proxy. Ein 401 fordert sie für die Zielressource. Eine Anfrage kann auf beide treffen. Klären Sie deshalb vor der Passworteingabe, wer danach fragt.
Status und Authentifizierungsanforderung vergleichen
| Antwort | Anforderungsheader | Header für Zugangsdaten | Beteiligte Stelle |
|---|---|---|---|
| 407 Proxy Authentication Required | Proxy-Authenticate | Proxy-Authorization | Ein zwischengeschalteter Proxy |
| 401 Unauthorized | WWW-Authenticate | Authorization | Die Authentifizierung der Ursprungsressource |
Der Status ist ein wichtiger erster Hinweis, aber prüfen Sie den gesamten Austausch. Eine Seite mit der Zahl 407 im Text ist keine echte HTTP-407-Antwort. Ebenso kann eine individuelle Webanmeldeseite den Status 200 liefern und trotzdem eine Anmeldung auf Anwendungsebene verlangen.
Warum HTTPS-Anfragen schon vor der Website mit 407 scheitern können
Wenn ein gewöhnlicher HTTP-Proxy eine HTTPS-Anfrage transportiert, fordert der Client üblicherweise zuerst einen CONNECT-Tunnel an. Der Proxy kann für diese CONNECT-Anfrage eine Authentifizierung verlangen. Solange sie nicht abgeschlossen ist, wurde die TLS-Sitzung mit dem Ziel durch den Tunnel noch nicht aufgebaut. Ein anderer Website-API-Token wird diese Phase daher wahrscheinlich nicht reparieren.
Nutzen Sie eine Anfrage mit ausführlicher Ausgabe, um die Authentifizierungsanforderung einzuordnen:
curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/Ersetzen Sie den lokalen Listener durch Ihren und lesen Sie die erste Anforderung im Protokoll. Ein 407 während CONNECT kommt vor dem Ziel-TLS; nach einem erfolgreich aufgebauten Tunnel kann später ein 401 folgen.
Proxy-Zugangsdaten über die Proxy-Schnittstelle übergeben
Für einen Endpunkt und ein Konto von einem vertrauenswürdigen Administrator kann curl das Proxy-Authentifizierungsverfahren aushandeln und ein fehlendes Passwort abfragen:
curl --proxy http://proxy.example:8080 --proxy-anyauth --proxy-user alice https://example.com/Ersetzen Sie Beispielendpunkt und Benutzername durch die Angaben des Dienstes, den Sie nutzen dürfen. Nur den Benutzernamen anzugeben verhindert, dass das Passwort direkt im obigen Befehl steht. Welche Verfahren unterstützt werden, hängt vom Proxy und vom curl-Build ab. Prüfen Sie bei einer fehlgeschlagenen Aushandlung die tatsächliche Anforderung und die Fähigkeiten des Builds.
Die Proxy-Authentifizierungsoption ist von curls Option für die Benutzeranmeldung am Ursprungsserver getrennt. Fügen Sie keinen Authorization-Header für den Ursprungsserver als Ersatz für die Antwort auf eine Proxy-Anforderung hinzu. Leiten Sie Proxy-Zugangsdatenheader auch nicht manuell an fremde Anfragen weiter und speichern Sie sie nicht in anwendungsweit wiederverwendeten Headern.
Wenn der Proxy ständig 407 zurückgibt
- Prüfen Sie, ob Sie den vorgesehenen Proxyhost und Port verwenden.
- Prüfen Sie die vom Proxy angebotenen Verfahren, statt Basic vorauszusetzen.
- Prüfen Sie den Kontostatus und ob der Dienst ein bestimmtes Benutzernamenformat verlangt.
- Prüfen Sie die Übergabe von Sonderzeichen, wenn Zugangsdaten in einer URL stehen.
- Klären Sie, ob eine in den Browser integrierte Unternehmensauthentifizierung Unterstützung durch Laufzeitumgebung oder Plattform benötigt.
- Bitten Sie bei unzureichenden Clientdaten um eine bereinigte Anfragekennung oder einen bereinigten Serverprotokolleintrag.
Ein 403 oder ein abgelehntes CONNECT kann auch nach erfolgreicher Anmeldung eine Zugriffsrichtlinie widerspiegeln. Weitere Passwortversuche verschaffen keinen Zugang zu einem gesperrten Ziel.
Ziel-HTTPS schützt nicht jeden Austausch von Proxy-Zugangsdaten
Die Proxy-Authentifizierung kann vor dem Aufbau von Ziel-TLS stattfinden. Ist die Verbindung zum Proxy selbst unverschlüsselt und legt das Verfahren dort wiederverwendbare Zugangsdaten offen, schützt ein HTTPS-Ziel diesen Austausch nicht nachträglich. Wählen Sie einen zum Dienst passenden Transport und eine passende Authentifizierung. Senden Sie private Konten nicht an einen unbekannten öffentlichen Proxy.
Prüfen Sie ausführliche Protokolle vor dem Teilen. Selbst wenn ein Werkzeug übliche Zugangsdatenfelder verdeckt, können noch Benutzernamen, interne Endpunktnamen, Cookies oder andere identifizierende Angaben enthalten sein.