Stöd för resursdelning för korsande ursprung (CORS) för Azure Storage

Artikel
08/05/2023

Från och med version 2013-08-15 har Azure Storage-tjänsterna stöd för resursdelning för korsande ursprung (CORS) för blob-, tabell- och kötjänsterna. Filtjänsten stöder CORS från och med version 2015-02-21.

CORS är en HTTP-funktion som gör det möjligt för ett webbprogram som körs i en domän att komma åt resurser i en annan domän. Webbläsare implementerar en säkerhetsbegränsning som kallas princip för samma ursprung som förhindrar att en webbsida anropar API:er i en annan domän. CORS är ett säkert sätt att tillåta att en domän (ursprungsdomänen) anropar API:er i en annan domän. Mer information om CORS finns i CORS-specifikationen .

Du kan ange CORS-regler individuellt för var och en av Azure Storage-tjänsterna genom att anropa Ange blobtjänstegenskaper, Ange egenskaper för filtjänst, Ange kötjänstegenskaper och Ange egenskaper för tabelltjänst. När du har angett CORS-reglerna för tjänsten kommer en korrekt auktoriserad begäran mot tjänsten från en annan domän att utvärderas för att avgöra om den tillåts enligt de regler som du har angett.

Viktigt

CORS är inte en auktoriseringsmekanism. Alla begäranden som görs mot en lagringsresurs när CORS är aktiverat måste antingen ha ett giltigt auktoriseringshuvud eller göras mot en offentlig resurs.

CORS stöds för alla typer av lagringskonton förutom för allmänna v1- eller v2-lagringskonton på premium-prestandanivån.

Förstå CORS-begäranden

En CORS-begäran från en ursprungsdomän kan bestå av två separata begäranden:

En förhandsbegäran som kör frågor mot CORS-begränsningarna som tillhandahålls av tjänsten. Den preliminära begäran krävs om inte begärandemetoden är en enkel metod, vilket innebär GET, HEAD eller POST.
Den faktiska begäran som görs mot den önskade resursen.

Preflight-begäran

Den preliminära begäran frågar de CORS-begränsningar som har upprättats för lagringstjänsten av kontoägaren. Webbläsaren (eller annan användaragent) skickar en OPTIONS-begäran som innehåller begärandehuvudena, metoden och ursprungsdomänen. Lagringstjänsten utvärderar den avsedda åtgärden baserat på en förkonfigurerad uppsättning CORS-regler som anger vilka ursprungsdomäner, begärandemetoder och begärandehuvuden som kan anges för en faktisk begäran mot en lagringsresurs.

Om CORS är aktiverat för tjänsten och det finns en CORS-regel som matchar den preliminära begäran svarar tjänsten med statuskod 200 (OK) och innehåller de nödvändiga Access-Control huvudena i svaret.

Om CORS inte är aktiverat för tjänsten eller om ingen CORS-regel matchar den preliminära begäran svarar tjänsten med statuskod 403 (Förbjuden).

Om OPTIONS-begäran inte innehåller nödvändiga CORS-huvuden (huvudena Origin och Access-Control-Request-Method) svarar tjänsten med statuskod 400 (felaktig begäran).

Observera att en preliminär begäran utvärderas mot tjänsten (blob, fil, kö eller tabell) och inte mot den begärda resursen. Kontoägaren måste ha aktiverat CORS genom att ange lämpliga egenskaper för kontotjänsten för att begäran ska lyckas.

Faktisk begäran

När den preliminära begäran har accepterats och svaret returneras skickar webbläsaren den faktiska begäran mot lagringsresursen. Webbläsaren nekar den faktiska begäran omedelbart om den preliminära begäran avvisas.

Den faktiska begäran behandlas som en vanlig begäran mot lagringstjänsten. Förekomsten av Origin-huvudet anger att begäran är en CORS-begäran och att tjänsten kontrollerar de matchande CORS-reglerna. Om en matchning hittas läggs Access-Control huvuden till i svaret och skickas tillbaka till klienten. Om en matchning inte hittas returneras inte CORS-Access-Control huvuden.

Aktivera CORS för Azure Storage

CORS-regler anges på tjänstnivå, så du måste aktivera eller inaktivera CORS för varje tjänst (blob, fil, kö och tabell) separat. Som standard inaktiveras CORS för varje tjänst. Om du vill aktivera CORS måste du ange lämpliga tjänstegenskaper med version 2013-08-15 eller senare för blob-, kö- och tabelltjänsterna eller version 2015-02-21 eller för filtjänsten. Du aktiverar CORS genom att lägga till CORS-regler i tjänstegenskaperna. Mer information om hur du aktiverar eller inaktiverar CORS för en tjänst och hur du anger CORS-regler finns i Ange egenskaper för blobtjänsten, Ange egenskaper för filtjänst, Ange egenskaper för tabelltjänst och Ange kötjänstegenskaper.

Här är ett exempel på en enskild CORS-regel som anges via en Set Service Properties åtgärd:

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

Varje element som ingår i CORS-regeln beskrivs nedan:

AllowedOrigins: De ursprungsdomäner som tillåts att göra en begäran mot lagringstjänsten via CORS. Ursprungsdomänen är den domän som begäran kommer från. Observera att ursprunget måste vara en exakt skiftlägeskänslig matchning med ursprunget som användarens ålder skickar till tjänsten.

Du kan använda jokertecknet *i stället för en angiven domän för att tillåta att alla ursprungsdomäner gör begäranden via CORS. Du kan också använda jokertecknet i stället för en underdomän så att alla underdomäner i en viss domän kan göra begäranden via CORS. I exemplet ovan kan alla underdomäner av contoso.com göra begäranden via CORS, medan endast begäranden från underdomänen wwwfabrikam.com för tillåts via CORS.
AllowedMethods: De metoder (HTTP-begärandeverb) som ursprungsdomänen kan använda för en CORS-begäran. I exemplet ovan tillåts endast PUT-begäranden och GET-begäranden.
AllowedHeaders: Begärandehuvuden som ursprungsdomänen kan ange på CORS-begäran. I exemplet ovan tillåts alla metadatarubriker som börjar med x-ms-meta-data, x-ms-meta-targetoch x-ms-meta-abc . Observera att jokertecknet *anger att alla rubriker som börjar med det angivna prefixet tillåts.
ExposedHeaders: Svarshuvudena som kan skickas i svaret på CORS-begäran och exponeras av webbläsaren för begärandeutfärdaren. I exemplet ovan instrueras webbläsaren att exponera alla rubriker som börjar med x-ms-meta.
MaxAgeInSeconds: Den maximala tid som en webbläsare ska cachelagras den preliminära OPTIONS-begäran.

Azure Storage-tjänsterna har stöd för att ange prefix för både elementen AllowedHeaders och ExposedHeaders . Om du vill tillåta en kategori med rubriker kan du ange ett gemensamt prefix för den kategorin. Om du till exempel anger x-ms-meta* som en prefixrubrik upprättas en regel som matchar alla rubriker som börjar med x-ms-meta.

Följande begränsningar gäller för CORS-regler:

Du kan ange upp till fem CORS-regler per lagringstjänst (blob, fil, tabell och kö).
Den maximala storleken på alla CORS-regelinställningar för begäran, exklusive XML-taggar, får inte överstiga 2 KiB.
Längden på en tillåten rubrik, exponerad rubrik eller tillåtet ursprung får inte överstiga 256 tecken.
Tillåtna rubriker och synliga rubriker kan vara något av följande:
- Literalrubriker, där det exakta rubriknamnet anges, till exempel x-ms-meta-processed. Högst 64 literalrubriker kan anges i begäran.
- Prefixrubriker, där ett prefix för rubriken tillhandahålls, till exempel x-ms-meta-data*. Om du anger ett prefix på det här sättet tillåts eller exponeras alla rubriker som börjar med det angivna prefixet. Högst två prefixrubriker kan anges i begäran.
De metoder (eller HTTP-verb) som anges i elementet AllowedMethods måste överensstämma med de metoder som stöds av Azure Storage-tjänstens API:er. Metoder som stöds är DELETE, GET, HEAD, MERGE, POST, PATCH, OPTIONS och PUT.

Förstå CORS-regelutvärderingslogik

När en lagringstjänst tar emot en preliminär eller faktisk begäran utvärderas begäran baserat på de CORS-regler som du har upprättat för tjänsten via lämplig åtgärd för att ange tjänstegenskaper. CORS-regler utvärderas i den ordning de angavs i begärandetexten för åtgärden Ange tjänstegenskaper.

CORS-regler utvärderas på följande sätt:

Först kontrolleras begärans ursprungsdomän mot de domäner som anges för -elementet AllowedOrigins . Om ursprungsdomänen finns med i listan, eller om alla domäner tillåts med jokertecknet *, fortsätter utvärderingen av reglerna. Om ursprungsdomänen inte ingår misslyckas begäran.
Därefter kontrolleras metoden (eller HTTP-verbet) för begäran mot de metoder som anges i -elementet AllowedMethods . Om metoden ingår i listan fortsätter regelutvärderingen. annars misslyckas begäran.
Om begäran matchar en regel i ursprungsdomänen och dess -metod väljs den regeln för att bearbeta begäran och inga ytterligare regler utvärderas. Innan begäran kan lyckas kontrolleras dock alla huvuden som anges i begäran mot de rubriker som anges i -elementet AllowedHeaders . Om de skickade huvudena inte matchar de tillåtna huvudena misslyckas begäran.

Eftersom reglerna bearbetas i den ordning de finns i begärandetexten rekommenderar bästa praxis att du anger de mest restriktiva reglerna för ursprung först i listan, så att dessa utvärderas först. Ange regler som är mindre restriktiva – till exempel en regel för att tillåta alla ursprung – i slutet av listan.

Exempel – Utvärdering av CORS-regler

I följande exempel visas en partiell begärandetext för en åtgärd för att ange CORS-regler för lagringstjänsterna. Mer information om hur du skapar begäran finns i Ange egenskaper för Blob Service, Ange egenskaper för filtjänst, Ange kötjänstegenskaper och Ange tabelltjänstegenskaper .

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

Överväg sedan följande CORS-begäranden:

Metod	Ursprung	Begärandehuvuden	Regelmatchning	Resultat
PUT	`http://www.contoso.com`	`x-ms-blob-content-type`	Första regeln	Klart
GET	`http://www.contoso.com`	`x-ms-blob-content-type`	Andra regeln	Klart
GET	`http://www.contoso.com`	`x-ms-client-request-id`	Andra regeln	Fel

Den första begäran matchar den första regeln – ursprungsdomänen matchar det tillåtna ursprunget, metoden matchar de tillåtna metoderna och rubriken matchar de tillåtna huvudena – och så lyckas.

Den andra begäran matchar inte den första regeln eftersom metoden inte matchar de tillåtna metoderna. Den matchar dock den andra regeln, så den lyckas.

Den tredje begäran matchar den andra regeln i dess ursprungsdomän och -metod, så inga ytterligare regler utvärderas. x-ms-client-request-id Huvudet tillåts dock inte av den andra regeln, så begäran misslyckas, trots att semantiken för den tredje regeln skulle ha gjort det möjligt för den att lyckas.

Anteckning

Även om det här exemplet visar en mindre restriktiv regel före en mer restriktiv regel är bästa praxis i allmänhet att först lista de mest restriktiva reglerna.

Förstå hur Vary-huvudet anges

Rubriken Vary är en HTTP/1.1-standardrubrik som består av en uppsättning fält för begärandehuvud som meddelar webbläsaren eller användaragenten om de kriterier som har valts av servern för att bearbeta begäran. Rubriken Vary används främst för cachelagring av proxyservrar, webbläsare och CDN:er, som använder den för att avgöra hur svaret ska cachelagras. Mer information finns i specifikationen för vary-huvudet.

När webbläsaren eller en annan användaragent cachelagrar svaret från en CORS-begäran cachelagras ursprungsdomänen som det tillåtna ursprunget. När en andra domän utfärdar samma begäran för en lagringsresurs när cachen är aktiv hämtar användaragenten den cachelagrade ursprungsdomänen. Den andra domänen matchar inte den cachelagrade domänen, så begäran misslyckas när den annars skulle lyckas. I vissa fall anger Vary Azure Storage -huvudet till Origin för att instruera användaragenten att skicka efterföljande CORS-begäran till tjänsten när den begärande domänen skiljer sig från det cachelagrade ursprunget.

Azure Storage anger Vary rubriken till Origin för faktiska GET/HEAD-begäranden i följande fall:

När ursprungsbegäran exakt matchar det tillåtna ursprunget som definieras av en CORS-regel. För att vara en exakt matchning kanske CORS-regeln inte innehåller jokertecknet *.
Det finns ingen regel som matchar begärans ursprung, men CORS är aktiverat för lagringstjänsten.

Om en GET/HEAD-begäran matchar en CORS-regel som tillåter alla ursprung anger svaret att alla ursprung är tillåtna och användaragentens cache tillåter efterföljande begäranden från alla ursprungsdomäner medan cachen är aktiv.

Observera att för begäranden som använder andra metoder än GET/HEAD kommer lagringstjänsterna inte att ange Vary huvudet, eftersom svar på dessa metoder inte cachelagras av användaragenter.

Följande tabell visar hur Azure Storage svarar på GET/HEAD-begäranden baserat på de tidigare nämnda fallen:

Ursprungsrubrik som finns på begäran	CORS-regler har angetts för den här tjänsten	*Matchande regel finns som tillåter alla ursprung ()**	Matchningsregeln finns för exakt ursprungsmatchning	Svaret innehåller Vary-huvudet inställt på Ursprung	*Svaret innehåller Access-Control-Allowed-Origin: ""**	Svaret innehåller Access-Control-Exposed-Headers
Inga	Inga	Inga	Inga	Inga	Inga	Inga
Inga	Ja	Inga	Inga	Ja	Inga	Inga
Inga	Ja	Ja	Inga	Inga	Ja	Ja
Ja	Inga	Inga	Inga	Inga	Inga	Inga
Ja	Ja	Inga	Ja	Ja	Inga	Ja
Ja	Ja	Inga	Inga	Ja	Inga	Inga
Ja	Ja	Ja	Inga	Inga	Ja	Yes

Fakturering för CORS-begäranden

Lyckade förhandsbegäranden debiteras om du har aktiverat CORS för någon av lagringstjänsterna för ditt konto (genom att anropa Ange egenskaper för Blob Service, Ange kötjänstegenskaper, Ange egenskaper för filtjänst eller Ange egenskaper för tabelltjänst). Om du vill minimera avgifterna bör du överväga att ange ett stort värde för elementet MaxAgeInSeconds i CORS-reglerna så att användaragenten cachelagrar begäran.

Misslyckade förinställda begäranden faktureras inte.

Se även

Resursdelningsspecifikation för korsande ursprung i W3C