VENDITE: 1-800-867-1389

Supporto della condivisione delle risorse tra le origini (CORS) per i servizi di archiviazione Azure

Aggiornamento: novembre 2013

A partire dalla versione 2013-08-15, i servizi di archiviazione di Azure supportano la condivisione delle risorse multiorigine (CORS) per i servizi BLOB, tabelle e di accodamento. La condivisione CORS è una funzionalità HTTP che consente a un'applicazione web in un dominio di accedere alle risorse di un altro dominio. Nei browser web è implementata una restrizione di sicurezza detta regola della stessa origine che impedisce a una pagina web di chiamare API in un dominio diverso. La condivisione CORS offre una modalità sicura per consentire a un dominio (quello di origine) di chiamare API in un altro dominio. Per ulteriori dettagli sull'argomento, vedere la specifica CORS.

È possibile stabilire singole regole CORS per ogni servizio di archiviazione chiamando Set Blob Service Properties, Set Queue Service Properties e Set Table Service Properties. Dopo aver impostato le regole CORS per il servizio, un'eventuale richiesta correttamente autenticata, proveniente da un dominio diverso ed eseguita nei confronti del servizio, verrà valutata per determinare se è consentita in base alle regole specificate.

noteNota
La condivisione CORS non è un meccanismo di autenticazione. Qualsiasi richiesta eseguita nei confronti di una risorsa di archiviazione quando la condivisione CORS è abilitata deve riportare un'opportuna firma di autenticazione o deve essere eseguita nei confronti di una risorsa pubblica.

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

  • Una richiesta preliminare, che esegue query sulle restrizioni per la condivisione 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 vera e propria, eseguita nei confronti della risorsa desiderata.

La richiesta preliminare esegue una query sulle restrizioni per la condivisione CORS definite per il servizio di archiviazione dal proprietario dell'account. Dal browser web (o da altro agente utente) viene inviata una richiesta OPTIONS che include il dominio di origine, il metodo e le intestazioni per la richiesta. Il servizio di archiviazione valuta l'operazione desiderata in base a un set di regole preconfigurate per la condivisione CORS, che determinano quali domini di origine, metodi e intestazioni di richiesta possono essere specificati in una richiesta effettiva nei confronti di 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 relative a origine e Access-Control-Request-Method), il servizio risponderà con un codice di stato 400 (Richiesta non valida).

Le richieste preliminari vengono valutate rispetto al servizio (BLOB, coda e tabella) e non rispetto alla risorsa richiesta. Perché la richiesta abbia esito positivo, il proprietario dell'account deve aver abilitato la condivisione CORS come parte delle proprietà del servizio dell'account stesso.

Una volta accettata la richiesta preliminare e restituita la risposta, la richiesta effettiva viene inviata dal browser nei confronti della 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 nei confronti del 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 vengono inviate di nuovo al client. Se non rilevata trovata alcuna corrispondenza, le intestazioni Access-Control CORS non vengono restituite.

Le regole CORS vengono stabilite a livello di servizio, pertanto è necessario abilitare o disabilitare la condivisione CORS separatamente per ogni servizio (BLOB, coda e tabella). Per impostazione predefinita, la condivisione CORS è disabilitata per ciascun servizio. Per abilitare la condivisione CORS, è necessario definire le proprietà adeguate del servizio tramite la versione 2013-08-15 o successive e aggiungere le regole CORS alle proprietà del servizio. Per informazioni su come abilitare o disabilitare la condivisione CORS per un servizio e su come stabilire le relative regole, fare riferimento a Set Blob Service Properties, Set Table Service Properties e Set Queue Service Properties.

Di seguito è riportato un esempio di una regola CORS singola, specificata tramite un'operazione di impostazione delle proprietà del servizio:

<Cors>    
      <CorsRule>
            <AllowedOrigins>http://www.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>

Di seguito è riportata la descrizione di ogni elemento incluso nella regola CORS:

  • AllowedOrigins: 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. È inoltre possibile utilizzare il carattere jolly "*" per consentire a tutti i domini di origine di effettuare richieste tramite condivisione CORS. Nell'esempio precedente, ai domini http://www.contoso.com e http://www.fabrikam.com è consentito effettuare richieste nei confronti del servizio tramite condivisione CORS.

  • AllowedMethods: metodi (verbi di richiesta HTTP) che possono essere utilizzati dal dominio di origine per una richiesta CORS. Nell'esempio precedente sono consentite solo le richieste PUT e GET.

  • AllowedHeaders: intestazioni di richiesta che possono essere specificate dal dominio di origine 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: 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: quantità di tempo massima in cui la richiesta OPTIONS preliminare deve essere memorizzata nella cache di un browser.

I servizi di archiviazione di Azure supportano la specifica di intestazioni con prefisso per gli elementi AllowedHeaders e 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 si applicano le limitazioni seguenti:

  • È possibile specificare un massimo di cinque regole CORS per servizio di archiviazione (BLOB, tabella e coda).

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

  • 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, in cui viene fornito il nome esatto dell'intestazione, ad esempio x-ms-meta-processed. È possibile specificare nella richiesta 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 inizia con il prefisso specificato. È possibile specificare nella richiesta un massimo di due intestazioni con prefisso.

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

Quando un servizio di archiviazione riceve una richiesta preliminare o effettiva, valuta quest'ultima in base alle regole CORS definite per il servizio tramite l'opportuna operazione di impostazione delle proprietà del servizio. Le regole CORS vengono valutate nell'ordine in cui sono state impostate nel corpo della richiesta relativo all'operazione di impostazione delle proprietà del servizio.

Le regole CORS sono 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, altrimenti 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.

Nell'esempio seguente viene illustrato un corpo di richiesta parziale per un'operazione di impostazione delle regole CORS per i servizi di archiviazione. Per informazioni dettagliate sulla costruzione della richiesta, vedere Set Blob Service Properties, Set Queue Service Properties e Set Table Service Properties.

<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:

 

Request

Response

Method

Origin

Request headers

Rule Match

Result

PUT

http://www.contoso.com

x-ms-blob-content-type

Prima regola

Esito positivo

GET

http://www.contoso.com

x-ms-blob-content-type

Seconda regola

Esito positivo

GET

http://www.contoso.com

x-ms-client-request-id

Seconda regola

Esito negativo

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), quindi 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.

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

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 stessa. Il secondo dominio non corrisponde al dominio presente nella cache, quindi l'esito della richiesta è negativo quando avrebbe potuto essere positivo. In alcuni casi, in Archiviazione di Microsoft Azure l'intestazione Vary viene impostata su Origine per indicare all'agente utente di inviare la richiesta CORS successiva al servizio quando il dominio della richiesta è diverso dall'origine memorizzata nella cache.

In Archiviazione di Microsoft Azure l'intestazione Vary viene impostata su Origine per le richieste GET/HEAD effettive nei seguenti casi:

  • 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.

Nel caso in cui una richiesta GET/HEAD corrisponda a una regola CORS che consente tutte le origini, la risposta indica che tutte le origini sono consentite e, finché resterà 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 di Archiviazione di Microsoft Azure alle richieste GET/HEAD in base ai casi riportati in precedenza:

 

Richiesta

Tipo di account e risultato della valutazione della regola

Risposta

Intestazione di origine presente su richiesta

Regole CORS specificate per questo servizio

Presenza di regola di corrispondenza che consente tutte le origini (*)

Presenza di regola per l'esatta corrispondenza dell'origine

Risposta con intestazione Vary impostata su Origine

Risposta con l'inclusione di Access-Control-Allowed-Origin: "*"

Risposta con l'inclusione di Access-Control-Exposed-Headers

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

No

Le richieste preliminari con esito positivo vengono addebitate qualora la condivisione CORS sia stata abilitata per i servizi di archiviazione dell'account (chiamando Set Blob Service Properties, Set Queue Service Properties o Set Table Service Properties). 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 addebitate.

Vedere anche

Il documento è risultato utile?
(1500 caratteri rimanenti)
Grazie per i commenti inviati.
Mostra:
© 2014 Microsoft