Proxy-Authenticate
Baseline Widely available
This feature is well established and works across many devices and browser versions. It’s been available across browsers since July 2015.
Der HTTP-Proxy-Authenticate
-Antwortheader definiert die Authentifizierungsmethode (oder Challenge), die verwendet werden sollte, um auf eine Ressource hinter einem Proxy-Server zuzugreifen.
Er wird in einer 407 Proxy Authentication Required
-Antwort gesendet, damit sich ein Client bei einem Proxy, der eine Authentifizierung erfordert, identifizieren kann.
Header-Typ | Antwortheader |
---|---|
Verbotener Header-Name | Ja |
Syntax
Eine durch Kommas getrennte Liste von einem oder mehreren Authentifizierungs-Herausforderungen:
Proxy-Authenticate: <challenge>
Dabei besteht eine <challenge>
aus einem <auth-scheme>
, gefolgt von einem optionalen <token68>
oder einer kommagetrennten Liste von <auth-params>
:
challenge = <auth-scheme> <auth-param>, …, <auth-paramN> challenge = <auth-scheme> <token68>
Zum Beispiel:
Proxy-Authenticate: <auth-scheme>
Proxy-Authenticate: <auth-scheme> token68
Proxy-Authenticate: <auth-scheme> auth-param1=param-token1
Proxy-Authenticate: <auth-scheme> auth-param1=param-token1, …, auth-paramN=param-tokenN
Das Vorhandensein eines token68
oder von Authentifizierungs-Parametern hängt vom gewählten <auth-scheme>
ab.
Zum Beispiel erfordert Basisauthentifizierung ein <realm>
und erlaubt die optionale Verwendung des charset
-Schlüssels, unterstützt jedoch kein token68
:
Proxy-Authenticate: Basic realm="Dev", charset="UTF-8"
Direktiven
<auth-scheme>
-
Ein nicht case-sensitiver Token, der das verwendete Authentifizierungsschema angibt. Einige der gängigsten Typen sind
Basic
,Digest
,Negotiate
undAWS4-HMAC-SHA256
. IANA führt eine Liste von Authentifizierungsschemata, aber es gibt auch andere Schemata, die von Hosting-Diensten angeboten werden. <auth-param>
Optional-
Ein Authentifizierungs-Parameter, dessen Format vom
<auth-scheme>
abhängt.<realm>
wird unten beschrieben, da es ein häufiger Authentifizierungs-Parameter unter vielen Authentifizierungsschemata ist.<realm>
Optional-
Der String
realm
gefolgt von=
und einem in Anführungszeichen gesetzten String, der einen geschützten Bereich beschreibt, z.B.realm="staging environment"
. Ein Realm ermöglicht es einem Server, die Bereiche, die er schützt, zu unterteilen (wenn dies von einem Schema unterstützt wird, das solche Unterteilungen zulässt). Einige Clients zeigen diesen Wert dem Benutzer an, um ihn darüber zu informieren, welche speziellen Anmeldedaten erforderlich sind — obwohl die meisten Browser dies eingestellt haben, um Phishing entgegenzuwirken. Der einzige zuverlässig unterstützte Zeichensatz für diesen Wert istus-ascii
. Wenn kein Realm angegeben ist, zeigen Clients oft einen formatierten Hostnamen anstelle dessen.
<token68>
Optional-
Ein Token, das für einige Schemata nützlich sein kann. Das Token erlaubt die 66 unreservierten URI-Zeichen plus einige andere. Es kann eine base64, base64url, base32 oder base16 (Hex)-Kodierung enthalten, mit oder ohne Padding, aber ohne Leerzeichen. Die
token68
-Alternative zu auth-param-Listen wird für die Kompatibilität mit älteren Authentifizierungsschemata unterstützt.
Im Allgemeinen müssen Sie die relevanten Spezifikationen für die benötigten Authentifizierungs-Parameter für jedes <auth-scheme>
überprüfen.
Hinweis:
Weitere Informationen zu Authentifizierungs-Parametern finden Sie unter WWW-Authenticate
.
Beispiele
Proxy-Authenticate Basic auth
Die folgende Antwort zeigt, dass ein Basic-Auth-Schema mit einem Realm erforderlich ist:
Proxy-Authenticate: Basic realm="Staging server"
Spezifikationen
Specification |
---|
HTTP Semantics # field.proxy-authenticate |
Browser-Kompatibilität
BCD tables only load in the browser