HTTP
Origine incrociata e controllo di accesso

Osservazioni

Cliente: invio di una richiesta di condivisione delle risorse tra origini (CORS)

Una richiesta di origine incrociata deve essere inviata includendo l'intestazione Origin . Questo indica da dove è originata la richiesta. Ad esempio, una richiesta di origine incrociata da http://example.com a http://example.org potrebbe essere simile a questa:

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

Il server utilizzerà questo valore per determinare se la richiesta è autorizzata.

Server: risposta a una richiesta CORS

La risposta a una richiesta CORS deve includere un'intestazione Access-Control-Allow-Origin , che impone quali origini sono autorizzate a utilizzare la risorsa CORS. Questa intestazione può assumere uno dei tre valori:

• Un'origine In questo modo solo le richieste provenienti da tale origine .
• Il personaggio * . Ciò consente richieste da qualsiasi origine .
• La stringa null . Ciò non consente richieste CORS .

Ad esempio, alla ricezione di una richiesta CORS dall'origine http://example.com , se example.com è un'origine autorizzata, il server restituirà questa risposta:

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

Una risposta di qualsiasi origine consentirebbe anche questa richiesta, vale a dire:

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

Consentire credenziali utente o sessione

Consentendo alle credenziali dell'utente o alla sessione dell'utente di essere inviata con una richiesta CORS, il server può conservare i dati utente attraverso le richieste CORS. Ciò è utile se il server deve controllare se l'utente è loggato prima di fornire dati (ad esempio, eseguendo un'azione solo se un utente ha effettuato l'accesso - ciò richiederebbe la richiesta CORS di essere inviata con credenziali).

Questo può essere ottenuto lato server per le richieste preflight, inviando l'intestazione Access-Control-Allow-Credentials in risposta alla richiesta di preflight OPTIONS . Prendi il seguente caso di una richiesta CORS per DELETE una risorsa:

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 line indica che la seguente richiesta DELETE CORS può essere inviata con le credenziali dell'utente.

Richieste di verifica preliminare

Una richiesta CORS di base può utilizzare uno dei due soli metodi:

• OTTENERE
• INVIARE

e solo alcune intestazioni selezionate. Le richieste POST CORS possono inoltre scegliere tra solo tre tipi di contenuto.

Per evitare questo problema, le richieste che desiderano utilizzare altri metodi, intestazioni o tipi di contenuto devono prima emettere una richiesta di preflight , che è una richiesta OPTIONS che include intestazioni di richiesta di controllo dell'accesso. Ad esempio, questa è una richiesta di preflight che controlla se il server accetta una richiesta PUT che include un'intestazione DNT :

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

Server: risposta alle richieste di verifica preliminare

Quando un server riceve una richiesta di verifica preliminare, deve verificare se supporta il metodo e le intestazioni richieste e inviare una risposta che indica la sua capacità di supportare la richiesta, nonché qualsiasi altro dato consentito (come le credenziali).

Questi sono indicati nelle intestazioni Allow-control Allow. Il server può anche inviare un'intestazione Max-Age controllo accessi, indicando per quanto tempo è possibile memorizzare la risposta di preflight.

Questo è ciò che un ciclo richiesta-risposta per una richiesta di preflight può avere:

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