HTTP
Cross Origin och Access Control

Anmärkningar

Klient: skicka en begäran om delning av resursdelning (CORS)

En begäran över ursprung måste skickas inklusive Origin rubriken. Detta indikerar varifrån begäran har sitt ursprung. Exempelvis skulle en förfrågning över ursprung från http://example.com till http://example.org se så här ut:

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

Servern kommer att använda detta värde för att avgöra om begäran är auktoriserad.

Server: svarar på en CORS-begäran

Svaret på en CORS-begäran måste innehålla en Access-Control-Allow-Origin rubrik, som dikterar vilket ursprung som tillåts använda CORS-resursen. Den här rubriken kan ta ett av tre värden:

• Ett ursprung. Att göra detta tillåter endast förfrågningar från det här ursprunget .
• Karaktären * . Detta tillåter förfrågningar från alla ursprung .
• Strängen null . Detta tillåter inga CORS-förfrågningar .

Till exempel vid mottagning av en CORS-begäran från ursprunget http://example.com , om example.com är ett godkänt ursprung, skickade servern tillbaka detta svar:

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

Ett svar från alla ursprung skulle också tillåta denna begäran, dvs.

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

Tillåter användaruppgifter eller session

Genom att låta användaruppgifter eller användarens session skickas med en CORS-begäran kan servern fortsätta användardata över CORS-förfrågningar. Detta är användbart om servern måste kontrollera om användaren är inloggad innan han tillhandahåller data (till exempel, bara utföra en åtgärd om en användare är inloggad - detta kräver att CORS-begäran skickas med referenser).

Detta kan uppnås på serversidan för förbelysade förfrågningar genom att skicka Access-Control-Allow-Credentials huvudet som svar på OPTIONS preflight-begäran. Ta följande fall med en CORS-begäran om att DELETE en resurs:

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

Access-Control-Allow-Credentials: true linjen indikerar att följande DELETE CORS-begäran kan skickas med användaruppgifter.

Förfrågningsförfrågningar

En grundläggande CORS-begäran får använda en av endast två metoder:

• SKAFFA SIG
• POSTA

och bara några få rubriker. POST CORS-förfrågningar kan dessutom välja mellan endast tre innehållstyper.

För att undvika det här problemet måste förfrågningar som vill använda andra metoder, rubriker eller innehållstyper först utfärda en preflight- begäran, som är en OPTIONS begäran som innehåller begäran om åtkomstkontroll. Till exempel är detta en preflight-begäran som kontrollerar om servern accepterar en PUT begäran som innehåller en DNT rubrik:

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

Server: svara på förfrågningsförfrågningar

När en server tar emot en preflight-begäran, måste den kontrollera om den stöder den begärda metoden och rubrikerna och skicka tillbaka ett svar som indikerar dess förmåga att stödja begäran, såväl som alla andra tillåtna data (som referenser).

Dessa anges i åtkomstkontroll Tillåt rubriker. Servern kan också skicka tillbaka en åtkomstkontroll Max-Age rubrik, som indikerar hur länge preflight-svaret kan sparas i cache.

Så här kan en begäran-svarcykel för en preflight-begäran se ut:

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