HTTP
Herkunfts- und Zugriffskontrolle
Suche…
Bemerkungen
Die urheberrechtliche Ressourcenfreigabe ermöglicht dynamische Anforderungen zwischen Domänen, wobei häufig Techniken wie AJAX verwendet werden . Während das Scripting die meiste Arbeit erledigt, muss der HTTP-Server die Anfrage mit den richtigen Kopfzeilen unterstützen.
Client: Senden einer CORS-Anforderung (Cross-Origin Resource Sharing)
Eine Querursprungsanforderung muss einschließlich den gesendet wird Origin
- Header. Dies gibt an, woher die Anfrage stammt. Eine Ursprungsübergreifende Anfrage von http://example.com
an http://example.org
würde beispielsweise so aussehen:
GET /cors HTTP/1.1
Host: example.org
Origin: example.com
Der Server verwendet diesen Wert, um zu bestimmen, ob die Anforderung autorisiert ist.
Server: Antworten auf eine CORS-Anfrage
Die Antwort auf eine CORS-Anforderung muss einen Access-Control-Allow-Origin
Header enthalten, der vorschreibt, welche Ursprünge die CORS-Ressource verwenden dürfen. Dieser Header kann einen von drei Werten annehmen:
- Ein Ursprung Dies erlaubt nur Anfragen von diesem Ursprung .
- Das Zeichen
*
. Dies erlaubt Anfragen von jeder Herkunft . - Die Zeichenfolge
null
. Dies erlaubt keine CORS-Anfragen .
Wenn zum Beispiel eine CORS-Anfrage vom Ursprung http://example.com
empfangen wird, würde der Server diese Antwort http://example.com
, wenn example.com
ein autorisierter Ursprung ist:
HTTP/1.1 200 OK
Access-Control-Allow-Origin: example.com
Eine Any-Origin-Antwort würde auch diese Anfrage zulassen, dh:
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Zulassen von Benutzeranmeldeinformationen oder Sitzungen
Wenn Benutzeranmeldeinformationen oder die Benutzersitzung mit einer CORS-Anforderung gesendet werden können, kann der Server Benutzerdaten in allen CORS-Anforderungen beibehalten. Dies ist nützlich, wenn der Server prüfen muss, ob der Benutzer angemeldet ist, bevor er Daten bereitstellt (z. B. nur eine Aktion ausführen, wenn ein Benutzer angemeldet ist - dazu müsste die CORS-Anforderung mit Anmeldeinformationen gesendet werden).
Dies kann serverseitig für Preflight-Anforderungen erreicht werden, indem der Header Access-Control-Allow-Credentials
als Antwort auf die Preflight-Anfrage OPTIONS
. Nehmen Sie den folgenden Fall einer CORS-Anforderung an, um eine Ressource zu DELETE
:
OPTIONS /cors HTTP/1.1
Host: example.com
Origin: example.org
Access-Control-Request-Method: DELETE
HTTP/1.1 200 OK
Access-Control-Allow-Origin: example.org
Access-Control-Allow-Methods: DELETE
Access-Control-Allow-Credentials: true
Die Zeile Access-Control-Allow-Credentials: true
gibt an, dass die folgende DELETE
CORS-Anforderung mit Benutzeranmeldeinformationen gesendet werden kann.
Preflight-Anfragen
Eine grundlegende CORS-Anfrage kann eine von nur zwei Methoden verwenden:
- ERHALTEN
- POST
und nur wenige Kopfzeilen auswählen. POST CORS-Anforderungen können zusätzlich nur drei Inhaltstypen auswählen.
Um dieses Problem zu vermeiden, müssen Anforderungen, die andere Methoden, Header oder Inhaltstypen verwenden möchten, zuerst eine Preflight- Anforderung ausgeben, bei der es sich um eine OPTIONS
Anforderung handelt, die Header für die Zugriffssteuerung enthält. Dies ist beispielsweise eine Preflight-Anforderung, die prüft, ob der Server eine PUT
Anforderung akzeptiert, die einen DNT
Header enthält:
OPTIONS /cors HTTP/1.1
Host: example.com
Origin: example.org
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: DNT
Server: Antworten auf Preflight-Anfragen
Wenn ein Server eine Preflight-Anforderung empfängt, muss er prüfen, ob er die angeforderte Methode und die Header unterstützt, und eine Antwort zurücksenden, aus der hervorgeht, dass er die Anforderung unterstützen kann, sowie alle anderen zulässigen Daten (beispielsweise Anmeldeinformationen).
Diese werden in Access-Allow-Headern angezeigt. Der Server sendet möglicherweise auch einen Max-Age
Header für die Zugriffskontrolle Max-Age
, der angibt, wie lange die Preflight-Antwort zwischengespeichert werden kann.
So könnte ein Request-Response-Zyklus für eine Preflight-Anfrage aussehen:
OPTIONS /cors HHTP/1.1
Host: example.com
Origin: example.org
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: DNT
HTTP/1.1 200 OK
Access-Control-Allow-Origin: example.org
Access-Control-Allow-Methods: PUT
Access-Control-Allow-Headers: DNT