Condividi tramite

Supporto di Condivisione risorse tra origini (CORS) per Archiviazione di Azure

  • Articolo

A partire dalla versione 2013-08-15, i servizi di archiviazione Azure supportano la Condivisione risorse tra le origini (CORS) per i servizi Blob, tabelle e di accodamento. Il servizio File supporta CORS a partire dalla versione 2015-02-21.

CORS è una funzionalità HTTP che consente a un'applicazione Web in esecuzione in un dominio di accedere alle risorse in un altro dominio. I Web browser implementano una restrizione di sicurezza nota come criteri di origine stessa che impedisce a una pagina Web di chiamare le API in un dominio diverso; CORS offre un modo sicuro per consentire a un dominio (dominio di origine) di chiamare le API in un altro dominio. Per informazioni dettagliate su CORS, vedere la specifica CORS .

È possibile impostare le regole CORS singolarmente per ognuno dei servizi di archiviazione di Azure chiamando Imposta proprietà servizio BLOB, Imposta proprietà servizio file, Imposta proprietà servizio coda e Imposta proprietà servizio tabelle. Una volta impostate le regole CORS per il servizio, una richiesta correttamente autorizzata, eseguita al servizio da un dominio diverso, verrà valutata per determinare se è consentita in base alle regole specificate.

Importante

CORS non è un meccanismo di autorizzazione. Qualsiasi richiesta effettuata su una risorsa di archiviazione quando CORS è abilitata deve avere un'intestazione di autorizzazione valida oppure deve essere effettuata su una risorsa pubblica.

CORS è supportato per tutti i tipi di account di archiviazione, ad eccezione degli account di archiviazione per utilizzo generico v1 o v2 nel livello di prestazioni Premium.

Informazioni sulle richieste CORS

Una richiesta CORS proveniente da un dominio di origine può essere costituita da due richieste distinte:

  • Una richiesta preliminare, che esegue query sulle restrizioni di CORS imposte dal servizio. La richiesta preliminare è obbligatoria, a meno che il metodo di richiesta sia un metodo semplice, ovvero GET, HEAD o POST.

  • La richiesta effettiva, effettuata alla risorsa desiderata.

Richiesta preliminare

La richiesta preliminare esegue una query sulle restrizioni per la condivisione CORS definite per il servizio di archiviazione dal proprietario dell'account. Dal Web browser (o da altro agente utente) viene inviata una richiesta OPTIONS che include le intestazioni della richiesta, il metodo e il dominio di origine. Il servizio di archiviazione valuta l'operazione desiderata in base a un set di regole preconfigurate per la condivisione CORS, che specificano quali domini di origine, metodi e intestazioni di richiesta possono essere specificati in una richiesta effettiva a una risorsa di archiviazione.

Se la condivisione CORS è abilitata per il servizio ed è presente una regola CORS che corrisponde alla richiesta preliminare, il servizio risponde con il codice di stato 200 (OK) e include nella risposta le intestazioni Access-Control obbligatorie.

Se la condivisione CORS non è abilitata per il servizio o non è presente alcuna regola CORS corrispondente alla richiesta preliminare, il servizio risponderà con il codice di stato 403 (Accesso negato).

Se nella richiesta OPTIONS non sono contenute le intestazioni CORS obbligatorie (intestazioni Origin e Access-Control-Request-Method), il servizio risponderà con un codice di stato 400 (Richiesta non valida).

Si noti che una richiesta preliminare viene valutata rispetto al servizio (BLOB, File, Coda o Tabella) e non rispetto alla risorsa richiesta. Il proprietario dell'account deve avere abilitato CORS impostando le proprietà del servizio account appropriate in modo che la richiesta abbia esito positivo.

Richiesta effettiva

Una volta che la richiesta preliminare viene accettata e viene restituita la risposta, il browser invierà la richiesta effettiva alla risorsa di archiviazione. Se la richiesta preliminare viene rifiutata, il browser negherà immediatamente la richiesta effettiva.

La richiesta effettiva viene trattata come una normale richiesta al servizio di archiviazione. La presenza dell'intestazione di origine indica che si tratta di una richiesta CORS e che il servizio controllerà le corrispondenti regole CORS. Se viene rilevata una corrispondenza, le intestazioni Access-Control vengono aggiunte alla risposta e inviate di nuovo al client. In caso contrario, le intestazioni Access-Control CORS non vengono restituite.

Abilitazione di CORS per Archiviazione di Azure

Le regole CORS vengono impostate a livello di servizio, quindi è necessario abilitare o disabilitare CORS per ogni servizio (BLOB, file, coda e tabella) separatamente. Per impostazione predefinita, la condivisione CORS è disabilitata per ogni servizio. Per abilitare CORS, è necessario impostare le proprietà del servizio appropriate usando la versione 2013-08-15 o successiva per i servizi BLOB, coda e tabelle o versione 2015-02-21 o per il servizio file. È possibile abilitare CORS aggiungendo regole CORS alle proprietà del servizio. Per informazioni dettagliate su come abilitare o disabilitare CORS per un servizio e su come impostare le regole CORS, vedere Impostare proprietà del servizio BLOB,Impostare proprietà del servizio file, impostare proprietà del servizio tabelle e impostare le proprietà del servizio code.

Ecco un esempio di una singola regola CORS, specificata tramite un'operazione Set Service Properties :

<Cors>
    <CorsRule>  
        <AllowedOrigins>http://*.contoso.com, http://www.fabrikam.com</AllowedOrigins>  
        <AllowedMethods>PUT,GET</AllowedMethods>  
        <AllowedHeaders>x-ms-meta-data*,x-ms-meta-target*,x-ms-meta-abc</AllowedHeaders>  
        <ExposedHeaders>x-ms-meta-*</ExposedHeaders>  
        <MaxAgeInSeconds>200</MaxAgeInSeconds>  
    </CorsRule>  
<Cors>

Ciascun elemento incluso nella regola CORS è descritto di seguito:

  • AllowedOrigins: i domini di origine ai quali è consentito effettuare una richiesta nei confronti del servizio di archiviazione tramite condivisione CORS. Il dominio di origine è quello da cui proviene la richiesta. L'origine deve corrispondere esattamente, anche con distinzione tra maiuscole e minuscole, all'origine inviata al servizio dall'agente utente.

    È possibile usare il carattere jolly '*' al posto di un dominio specificato per consentire a tutti i domini di origine di effettuare richieste tramite CORS. È anche possibile usare il carattere jolly al posto di un sottodominio per consentire a tutti i sottodomini di un determinato dominio di effettuare richieste tramite CORS. Nell'esempio precedente, tutti i sottodomini di contoso.com possono effettuare richieste tramite CORS, mentre solo le richieste dal www sottodominio di fabrikam.com sono consentite tramite CORS.

  • AllowedMethods: i metodi (verbi di richiesta HTTP) che il dominio di origine può utilizzare per una richiesta CORS. Nell'esempio precedente sono consentite solo le richieste PUT e GET.

  • AllowedHeaders: le intestazioni di richiesta che il dominio di origine può specificare nella richiesta CORS. Nell'esempio precedente, sono consentite tutte le intestazioni di metadati che iniziano con x-ms-meta-data, x-ms-meta-target e x-ms-meta-abc. Il carattere jolly "*" indica che è consentita qualsiasi intestazione che inizi col prefisso specificato.

  • ExposedHeaders: le intestazioni di risposta che possono essere inviate in risposta alla richiesta CORS ed esposte al richiedente dal browser. Nell'esempio precedente, al browser viene richiesto di esporre qualsiasi intestazione che inizi con x-ms-meta.

  • MaxAgeInSeconds: la quantità massima di tempo in cui la richiesta preliminare OPTIONS deve essere memorizzata nella cache di un browser.

Il servizio archiviazione Azure supporta la specifica di intestazioni con prefisso sia per gli elementi AllowedHeaders che ExposedHeaders. Per consentire una categoria di intestazioni, è possibile specificare un prefisso comune a tale categoria. Ad esempio, specificando x-ms-meta* come intestazione con prefisso, viene impostata una regola corrispondente a tutte le intestazioni che iniziano con x-ms-meta.

Alle regole CORS vengono applicate le limitazioni seguenti:

  • È possibile specificare fino a cinque regole CORS per servizio di archiviazione (BLOB, file, tabella e coda).

  • Le dimensioni massime di tutte le impostazioni delle regole CORS nella richiesta, esclusi i tag XML, non devono superare 2 KiB.

  • La lunghezza di un'intestazione consentita, di un'intestazione esposta o di un'origine consentita non deve superare 256 caratteri.

  • Le intestazioni consentite e quelle esposte possono essere:

    • Intestazioni letterali, per cui viene fornito il nome esatto dell'intestazione, ad esempio x-ms-meta-processed. Nella richiesta è possibile specificare un massimo di 64 intestazioni letterali.
    • Intestazioni con prefisso, in cui viene fornito un prefisso dell'intestazione, ad esempio x-ms-meta-data*. Specificando un prefisso in questo modo, si consente o si espone qualsiasi intestazione che inizi con il prefisso specificato. Nella richiesta è possibile specificare un massimo di due intestazioni con prefisso.

  • I metodi (o verbi HTTP) specificati nell'elemento AllowedMethods devono essere conformi ai metodi supportati dalle API del servizio di archiviazione di Azure. I metodi supportati sono DELETE, GET, HEAD, MERGE, POST, PATCH, OPTIONS e PUT.

Informazioni sulla logica di valutazione delle regole CORS

Quando il servizio di archiviazione riceve una richiesta preliminare o effettiva, la valuta in base alle regole CORS definite per il servizio tramite l'operazione Set Service Properties appropriata. Le regole CORS vengono valutate nell'ordine in cui sono state impostate nel corpo della richiesta relativo all'operazione Set Service Properties.

Le regole CORS vengono valutate come segue:

  1. In primo luogo, il dominio di origine della richiesta viene confrontato con i domini elencati per l'elemento AllowedOrigins. Se il dominio di origine è incluso nell'elenco oppure tramite il carattere jolly "*" sono consentiti tutti i domini, la valutazione delle regole prosegue. Se il dominio di origine non è incluso, la richiesta ha esito negativo.

  2. Successivamente, il metodo (o verbo HTTP) della richiesta viene confrontato con i metodi elencati nell'elemento AllowedMethods. Se il metodo è incluso nell'elenco, la valutazione delle regole prosegue; in caso contrario, la richiesta ha esito negativo.

  3. Se la richiesta corrisponde a una regola nel relativo dominio di origine e nel relativo metodo, tale regola viene selezionata per elaborare la richiesta e non ne vengono valutate altre. Tuttavia, prima che la richiesta possa avere esito positivo, vengono controllate tutte le intestazioni specificate nella richiesta rispetto alle intestazioni elencate nell'elemento AllowedHeaders. Se le intestazioni inviate non corrispondono alle intestazioni consentite, la richiesta ha esito negativo.

Poiché le regole vengono elaborate nell'ordine in cui si trovano nel corpo della richiesta, nell'elenco è consigliabile specificare in primo luogo le regole più restrittive, in modo che vengano valutate per prime. Specificare le regole meno restrittive (ad esempio, una regola che consente tutte le origini) alla fine dell'elenco.

Esempio: valutazione di regole CORS

Nell'esempio seguente viene illustrato il corpo di una richiesta parziale per un'operazione di impostazione delle regole CORS per i servizi di archiviazione. Per informazioni dettagliate sulla costruzione della richiesta, vedere Impostare proprietà del servizio code, Impostare proprietà del servizio code e Impostare le proprietà del servizio tabelle.

<Cors>  
    <CorsRule>  
        <AllowedOrigins>http://www.contoso.com</AllowedOrigins>  
        <AllowedMethods>PUT,HEAD</AllowedMethods>  
        <MaxAgeInSeconds>5</MaxAgeInSeconds>  
        <ExposedHeaders>x-ms-*</ExposedHeaders>  
        <AllowedHeaders>x-ms-blob-content-type, x-ms-blob-content-disposition</AllowedHeaders>  
    </CorsRule>  
    <CorsRule>  
        <AllowedOrigins>*</AllowedOrigins>  
        <AllowedMethods>PUT,GET</AllowedMethods>  
        <MaxAgeInSeconds>5</MaxAgeInSeconds>  
        <ExposedHeaders>x-ms-*</ExposedHeaders>  
        <AllowedHeaders>x-ms-blob-content-type, x-ms-blob-content-disposition</AllowedHeaders>  
    </CorsRule>  
    <CorsRule>  
        <AllowedOrigins>http://www.contoso.com</AllowedOrigins>  
        <AllowedMethods>GET</AllowedMethods>  
        <MaxAgeInSeconds>5</MaxAgeInSeconds>  
        <ExposedHeaders>x-ms-*</ExposedHeaders>  
        <AllowedHeaders>x-ms-client-request-id</AllowedHeaders>  
    </CorsRule>  
</Cors>

Successivamente, considerare le seguenti richieste CORS:

Metodo Origine Intestazioni della richiesta Corrispondenza regola Risultato
PUT http://www.contoso.com x-ms-blob-content-type Prima regola Operazione riuscita
GET http://www.contoso.com x-ms-blob-content-type Seconda regola Operazione riuscita
GET http://www.contoso.com x-ms-client-request-id Seconda regola Operazioni non riuscite

La prima richiesta corrisponde alla prima regola (il dominio di origine corrisponde alle origini consentite, il metodo corrisponde ai metodi consentiti e l'intestazione corrisponde alle intestazioni consentite), pertanto ha esito positivo.

La seconda richiesta non corrisponde alla prima regola, perché il metodo non corrisponde ai metodi consentiti. Tuttavia corrisponde alla seconda regola, pertanto ha esito positivo.

La terza richiesta corrisponde alla seconda regola nel relativo metodo e dominio di origine, pertanto non vengono valutate altre regole. Tuttavia, l'intestazione x-ms-client-request-id non è consentita dalla seconda regola, quindi la richiesta ha esito negativo, anche se la semantica della terza regola ne avrebbe consentito l'esito positivo.

Nota

Sebbene nell'esempio sia riportata una regola meno restrittiva prima di una più restrittiva, in generale è consigliabile elencare prima le regole più restrittive.

Informazioni sulla procedura per impostare l'intestazione Vary

Vary è un'intestazione standard HTTP/1.1 costituita da un set di campi di intestazione della richiesta che indicano al browser o all'agente utente i criteri selezionati dal server per l'elaborazione della richiesta. L'intestazione Vary viene utilizzata principalmente per la memorizzazione nella cache da parte di proxy, browser e reti CDN, che la impiegano per determinare come deve essere memorizzata nella cache la risposta. Per informazioni dettagliate, vedere la specifica dell' intestazione Vary.

Quando la risposta a una richiesta CORS viene memorizzata nella cache dal browser o da un altro agente utente, il dominio di origine viene memorizzato nella cache come origine consentita. Se un secondo dominio invia la stessa richiesta per una risorsa di archiviazione mentre la cache è attiva, l'agente utente recupera il dominio di origine presente nella cache. Il secondo dominio non corrisponde al dominio presente nella cache, pertanto l'esito della richiesta è negativo quando avrebbe potuto essere positivo. In alcuni casi, Archiviazione di Azure imposta l'intestazione Vary su per Origin indicare all'agente utente di inviare la richiesta CORS successiva al servizio quando il dominio di richiesta differisce dall'origine memorizzata nella cache.

Archiviazione di Azure imposta l'intestazione Vary su Origin per le richieste GET/HEAD effettive nei casi seguenti:

  • Quando l'origine della richiesta corrisponde esattamente all'origine consentita definita da una regola CORS. Perché una corrispondenza sia esatta, la regola CORS non può includere il carattere jolly "*".

  • Non esiste alcuna regola corrispondente all'origine della richiesta, ma la condivisione CORS è abilitata per il servizio di archiviazione.

Se una richiesta GET/HEAD corrisponde a una regola CORS che consente tutte le origini, la risposta indica che tutte le origini sono consentite e, finché la cache resta attiva, la cache dell'agente utente consentirà le richieste successive provenienti da qualsiasi dominio di origine.

Per le richieste che utilizzano metodi diversi da GET/HEAD, l'intestazione Vary non verrà impostata dai servizi di archiviazione, poiché le risposte a questi metodi non vengono memorizzate nella cache dagli agenti utenti.

Nella tabella seguente viene indicata la risposta del servizio di archiviazione di Azure alle richieste GET/HEAD in base ai casi riportati in precedenza:

Intestazione di origine presente sulla richiesta Regole CORS specificate per questo servizio La regola di corrispondenza esiste che consente tutte le origini (*) Presenza di una regola per l'esatta corrispondenza dell'origine Risposta che include l'intestazione Vary impostata su Origin Risposta che include Access-Control-Allowed-Origin: "*" Risposta che include Access-Control-Exposed-Headers
No No No No No No No
No Sì No No Sì No No
No Sì Sì No No Sì Sì
Sì No No No No No No
Sì Sì No Sì Sì No Sì
Sì Sì No No Sì No No
Sì Sì Sì No No Sì Sì

Fatturazione per le richieste CORS

Le richieste di pre-verifica riuscite vengono fatturate se è stato abilitato CORS per uno dei servizi di archiviazione per l'account ( chiamando Imposta proprietà servizio BLOB, Imposta proprietà del servizio code, Imposta proprietà servizio file o Imposta proprietà servizio tabelle). Per ridurre le spese, impostare su un valore elevato l'elemento MaxAgeInSeconds nelle regole CORS, in modo che la richiesta venga memorizzata nella cache dall'agente utente.

Le richieste preliminari con esito negativo non verranno fatturate.

Vedi anche

Specifica del W3C relativa alla condivisione delle risorse multiorigine (CORS)