HTTP
Cross Origin en toegangscontrole

Opmerkingen

Klant: een CORS-aanvraag (Cross-Origin Resource Sharing) verzenden

Een verzoek cross-oorsprong moeten worden gestuurd met inbegrip van de Origin -header. Dit geeft aan waar het verzoek vandaan komt. Een verzoek van oorsprong van http://example.com naar http://example.org ziet er bijvoorbeeld als volgt uit:

GET /cors HTTP/1.1
Host: example.org
Origin: example.com

De server gebruikt deze waarde om te bepalen of het verzoek is geautoriseerd.

Server: reageren op een CORS-verzoek

Het antwoord op een CORS-verzoek moet een header voor Access-Control-Allow-Origin , die bepaalt welke oorsprong de CORS-bron mag gebruiken. Deze kop kan een van drie waarden aannemen:

• Een oorsprong. Als u dit doet, zijn alleen aanvragen van die oorsprong toegestaan .
• Het karakter * . Dit staat verzoeken van elke oorsprong toe .
• De tekenreeks is null . Dit staat geen CORS-aanvragen toe .

Bij ontvangst van een CORS-verzoek van de oorsprong http://example.com , als example.com een geautoriseerde oorsprong is, stuurt de server dit antwoord terug:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: example.com

Een antwoord van elke oorsprong zou dit verzoek ook toestaan, namelijk:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: *

Gebruikersreferenties of sessie toestaan

Door toe te staan dat gebruikersreferenties of de gebruikerssessie worden verzonden met een CORS-verzoek, kan de server gebruikersgegevens bewaren voor CORS-aanvragen. Dit is handig als de server moet controleren of de gebruiker is aangemeld voordat gegevens worden verstrekt (bijvoorbeeld alleen een actie uitvoeren als een gebruiker is aangemeld - hiervoor moet het CORS-verzoek met referenties worden verzonden).

Dit kan worden bereikt op de server voor preflight-aanvragen, door de header Access-Control-Allow-Credentials verzenden in reactie op het preflight-verzoek OPTIONS . Neem het volgende geval van een CORS-verzoek om een bron te 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

De regel Access-Control-Allow-Credentials: true geeft aan dat het volgende DELETE CORS-verzoek kan worden verzonden met gebruikersreferenties.

Preflight-aanvragen

Een standaard CORS-verzoek mag een van slechts twee methoden gebruiken:

• KRIJGEN
• POST

en slechts een paar geselecteerde headers. POST CORS-aanvragen kunnen bovendien kiezen uit slechts drie inhoudstypen.

Om dit probleem te voorkomen, moeten aanvragen die andere methoden, kopteksten of inhoudstypen willen gebruiken, eerst een preflight- aanvraag indienen. Dit is een OPTIONS aanvraag met toegangsbeheeraanvraagkopteksten. Dit is bijvoorbeeld een preflight-aanvraag die controleert of de server een PUT aanvraag met een DNT header accepteert:

OPTIONS /cors HTTP/1.1
Host: example.com
Origin: example.org
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: DNT

Server: reageren op preflight-aanvragen

Wanneer een server een preflight-aanvraag ontvangt, moet deze controleren of deze de gevraagde methode en headers ondersteunt en een antwoord terugsturen dat aangeeft in staat te zijn de aanvraag te ondersteunen, evenals andere toegestane gegevens (zoals referenties).

Deze worden aangegeven in toegangscontrole Headers toestaan. De server kan ook een Max-Age header voor toegangscontrole terugsturen, die aangeeft hoelang de preflight-respons kan worden gecached.

Dit is hoe een aanvraag-antwoordcyclus voor een preflight-aanvraag eruit zou kunnen zien:

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