CorS-ondersteuning (Cross-Origin Resource Sharing) voor Azure Storage

Vanaf versie 2013-08-15 ondersteunen de Azure-opslagservices Cross-Origin Resource Sharing (CORS) voor de blob-, tabel- en wachtrijservices. De bestandsservice ondersteunt CORS vanaf versie 2015-02-21.

CORS is een HTTP-functie waarmee een webtoepassing die wordt uitgevoerd onder één domein, toegang kan krijgen tot resources in een ander domein. Webbrowsers implementeren een beveiligingsbeperking die bekend staat als same-origin-beleid dat voorkomt dat een webpagina API's aanroept in een ander domein; CORS biedt een veilige manier om één domein (het oorspronkelijke domein) API's in een ander domein te laten aanroepen. Zie de CORS-specificatie voor meer informatie over CORS.

U kunt CORS-regels afzonderlijk instellen voor elk van de Azure Storage-services door Eigenschappen van Blob-serviceinstellen, Eigenschappenvan bestandsservice instellen, Eigenschappenvan wachtrijservice instellen en Eigenschappen van tabelservice instellenaan te roepen. Zodra u de CORS-regels voor de service hebt ingesteld, wordt een correct geautoriseerde aanvraag voor de service vanuit een ander domein geëvalueerd om te bepalen of deze is toegestaan volgens de regels die u hebt opgegeven.

Belangrijk

CORS is geen autorisatiemechanisme. Elke aanvraag die wordt ingediend bij een opslagresource wanneer CORS is ingeschakeld, moet een geldige autorisatieheader hebben of moeten worden gemaakt op een openbare resource.

CORS wordt ondersteund voor alle typen opslagaccounts, met uitzondering van opslagaccounts voor algemeen gebruik v1 of v2 in de Premium-prestatielaag.

Informatie over CORS-aanvragen

Een CORS-aanvraag van een oorsprongdomein kan bestaan uit twee afzonderlijke aanvragen:

  • Een voorlopige aanvraag, waarin de CORS-beperkingen worden opgevraagd die door de service zijn opgelegd. De eerste aanvraag is vereist, tenzij de aanvraagmethode een eenvoudige methode is,wat GET, HEAD of POST betekent.

  • De werkelijke aanvraag, gemaakt op de gewenste resource.

Aanvraag vooraf

De preflight-aanvraag vraagt de CORS-beperkingen op die door de accounteigenaar zijn ingesteld voor de opslagservice. De webbrowser (of een andere gebruikersagent) verzendt een OPTIONS-aanvraag die de aanvraagheaders, methode en oorsprongdomein bevat. De opslagservice evalueert de beoogde bewerking op basis van een vooraf geconfigureerde set CORS-regels die aangeven welke oorsprongdomeinen, aanvraagmethoden en aanvraagheaders kunnen worden opgegeven bij een daadwerkelijke aanvraag voor een opslagresource.

Als CORS is ingeschakeld voor de service en er een CORS-regel is die overeenkomt met de eerste aanvraag, reageert de service met statuscode 200 (OK) en worden de vereiste Access-Control-headers in het antwoord opgeslagen.

Als CORS niet is ingeschakeld voor de service of als er geen CORS-regel overeenkomt met de eerste aanvraag, reageert de service met statuscode 403 (Verboden).

Als de OPTIONS-aanvraag niet de vereiste CORS-headers bevat (de headers Origin en Access-Control-Request-Method), reageert de service met statuscode 400 (Bad request).

Houd er rekening mee dat een voorlopige aanvraag wordt geëvalueerd op basis van de service (Blob, File, Queue of Table) en niet op basis van de aangevraagde resource. De accounteigenaar moet CORS hebben ingeschakeld door de juiste accountservice-eigenschappen in te stellen om de aanvraag te laten slagen.

Werkelijke aanvraag

Zodra de eerste aanvraag is geaccepteerd en het antwoord wordt geretourneerd, stuurt de browser de daadwerkelijke aanvraag naar de opslagresource. De browser weigert de werkelijke aanvraag onmiddellijk als de voorlopige aanvraag wordt afgewezen.

De werkelijke aanvraag wordt behandeld als een normale aanvraag voor de opslagservice. De aanwezigheid van de Origin-header geeft aan dat de aanvraag een CORS-aanvraag is en dat de service de overeenkomende CORS-regels controleert. Als er een overeenkomst wordt gevonden, worden Access-Control headers toegevoegd aan het antwoord en teruggestuurd naar de client. Als er geen overeenkomst wordt gevonden, worden de CORS-Access-Control headers niet geretourneerd.

CORS inschakelen voor Azure Storage

CORS-regels worden ingesteld op serviceniveau, dus u moet CORS afzonderlijk in- of uitschakelen voor elke service (blob, bestand, wachtrij en tabel). CORS is standaard uitgeschakeld voor elke service. Als u CORS wilt inschakelen, moet u de juiste service-eigenschappen instellen met versie 2013-08-15 of hoger voor de blob-, wachtrij- en tabelservices, of versie 2015-02-21 of voor de bestandsservice. U kunt CORS inschakelen door CORS-regels toe te voegen aan de service-eigenschappen. Voor meer informatie over het in- of uitschakelen van CORS voor een service en het instellen van CORS-regels raadpleegt u Eigenschappen van blobserviceinstellen, Eigenschappenvan bestandsservice instellen, Eigenschappenvan tabelservice instellen en Eigenschappen van wachtrijservice instellen.

Hier is een voorbeeld van één CORS-regel, opgegeven via een Set Service Properties bewerking:

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

Elk element dat is opgenomen in de CORS-regel wordt hieronder beschreven:

  • AllowedOrigins: de oorspronkelijke domeinen die via CORS een aanvraag mogen indienen bij de opslagservice. Het oorspronkelijke domein is het domein van waaruit de aanvraag afkomstig is. Houd er rekening mee dat de oorsprong een exacte, casegevoelige overeenkomst moet zijn met de oorsprong die de leeftijd van de gebruiker naar de service verzendt.

    U kunt het jokerteken '*' in plaats van een opgegeven domein gebruiken om alle oorspronkelijke domeinen via CORS aanvragen te laten doen. U kunt ook het jokerteken gebruiken in plaats van een subdomein, zodat alle subdomeinen van een bepaald domein aanvragen kunnen doen via CORS. In het bovenstaande voorbeeld kunnen alle subdomeinen van aanvragen doen via CORS, terwijl alleen aanvragen van het subdomein van zijn toegestaan contoso.com www via fabrikam.com CORS.

  • AllowedMethods: de methoden (HTTP-aanvraagwoorden) die het oorspronkelijke domein kan gebruiken voor een CORS-aanvraag. In het bovenstaande voorbeeld zijn alleen PUT- en GET-aanvragen toegestaan.

  • AllowedHeaders: de aanvraagheaders die het oorspronkelijke domein kan opgeven voor de CORS-aanvraag. In het bovenstaande voorbeeld zijn alle metagegevensheaders die beginnen x-ms-meta-data met x-ms-meta-target , en x-ms-meta-abc toegestaan. Houd er rekening mee dat het jokerteken '*' aangeeft dat een header die begint met het opgegeven voorvoegsel is toegestaan.

  • ExposedHeaders: de antwoordheaders die kunnen worden verzonden als reactie op de CORS-aanvraag en die door de browser worden weergegeven aan de vereenigder van aanvragen. In het bovenstaande voorbeeld wordt de browser geïnstrueerd om headers weer te geven die beginnen met x-ms-meta .

  • MaxAgeInSeconds: de maximale tijd die een browser nodig heeft om de preflight OPTIONS-aanvraag in de cache op te nemen.

De Azure Storage-services ondersteunen het opgeven van voorvoegselheaders voor zowel de elementen AllowedHeaders als ExposedHeaders. Als u een categorie headers wilt toestaan, kunt u een gemeenschappelijk voorvoegsel voor die categorie opgeven. Als u bijvoorbeeld opgeeft als een header met voorvoegsel, wordt er een regel vastgelegd die overeen komt met alle x-ms-meta* headers die met x-ms-meta beginnen.

De volgende beperkingen zijn van toepassing op CORS-regels:

  • U kunt maximaal vijf CORS-regels per opslagservice opgeven (Blob, File, Table en Queue).

  • De maximale grootte van alle CORS-regelinstellingen voor de aanvraag, met uitzondering van XML-tags, mag niet groter zijn dan 2 KiB.

  • De lengte van een toegestane header, zichtbare header of toegestane oorsprong mag niet langer zijn dan 256 tekens.

  • Toegestane headers en zichtbare headers kunnen een van de volgende zijn:

    • Letterlijke headers, waarbij de exacte headernaam wordt opgegeven, zoals x-ms-meta-processed. Er kunnen maximaal 64 letterlijke headers worden opgegeven voor de aanvraag.
    • Voorvoegselheaders, waarbij een voorvoegsel van de header wordt opgegeven, zoals x-ms-meta-data. * Als u op deze manier een voorvoegsel opgeeft, worden headers die met het opgegeven voorvoegsel beginnen, al dan niet beschikbaar gemaakt. Er kunnen maximaal twee voorvoegselheaders worden opgegeven voor de aanvraag.
  • De methoden (of HTTP-woorden) die zijn opgegeven in het element AllowedMethods moeten voldoen aan de methoden die worden ondersteund door API's van Azure Storage-service. Ondersteunde methoden zijn DELETE, GET, HEAD, MERGE, POST, PATCH, OPTIONS en PUT.

Informatie over cors-regelevaluatielogica

Wanneer een opslagservice een actuele of daadwerkelijke aanvraag ontvangt, wordt die aanvraag geëvalueerd op basis van de CORS-regels die u hebt ingesteld voor de service via de juiste bewerking Service-eigenschappen instellen. CORS-regels worden geëvalueerd in de volgorde waarin ze zijn ingesteld in de aanvraag body van de bewerking Set Service Properties.

CORS-regels worden als volgt geëvalueerd:

  1. Eerst wordt het oorspronkelijke domein van de aanvraag gecontroleerd op basis van de domeinen die voor het element worden AllowedOrigins vermeld. Als het oorspronkelijke domein is opgenomen in de lijst of als alle domeinen zijn toegestaan met het jokerteken '*', wordt de evaluatie van regels verder gezet. Als het oorspronkelijke domein niet is opgenomen, mislukt de aanvraag.

  2. Vervolgens wordt de methode (of HTTP-woord) van de aanvraag gecontroleerd op de methoden die in het element worden AllowedMethods vermeld. Als de methode in de lijst is opgenomen, wordt de evaluatie van regels verder gezet; Zo niet, dan mislukt de aanvraag.

  3. Als de aanvraag overeenkomt met een regel in het oorspronkelijke domein en de methode ervan, wordt die regel geselecteerd om de aanvraag te verwerken en worden er geen verdere regels geëvalueerd. Voordat de aanvraag kan slagen, worden alle headers die zijn opgegeven in de aanvraag gecontroleerd op basis van de headers die in het element worden AllowedHeaders vermeld. Als de verzonden headers niet overeenkomen met de toegestane headers, mislukt de aanvraag.

Omdat de regels worden verwerkt in de volgorde waarin ze aanwezig zijn in de aanvraag body, raden best practices u aan om eerst de meest beperkende regels met betrekking tot oorsprongen in de lijst op te geven, zodat deze eerst worden geëvalueerd. Regels opgeven die minder beperkend zijn, bijvoorbeeld een regel om alle oorsprongen toe te staan, aan het einde van de lijst.

Voorbeeld: cors-regels evalueren

In het volgende voorbeeld ziet u een gedeeltelijke aanvraag voor een bewerking voor het instellen van CORS-regels voor de opslagservices. Zie Eigenschappen van Blob-service instellen,Eigenschappen van bestandsserviceinstellen, Eigenschappen van Wachtrijserviceinstellen en Eigenschappen van Tabelservice instellen voor meer informatie over het maken van de aanvraag.

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

Overweeg vervolgens de volgende CORS-aanvragen:

Methode Oorsprong Aanvraagheaders Regelmatch Resultaat
PUT http://www.contoso.com x-ms-blob-content-type Eerste regel Geslaagd
TOEVOEGEN http://www.contoso.com x-ms-blob-content-type Tweede regel Geslaagd
TOEVOEGEN http://www.contoso.com x-ms-client-request-id Tweede regel Fout

De eerste aanvraag komt overeen met de eerste regel: het oorspronkelijke domein komt overeen met de toegestane oorsprongen, de methode komt overeen met de toegestane methoden en de header komt overeen met de toegestane headers, en slaagt dus.

De tweede aanvraag komt niet overeen met de eerste regel omdat de methode niet overeen komt met de toegestane methoden. Deze komt echter overeen met de tweede regel, zodat deze slaagt.

De derde aanvraag komt overeen met de tweede regel in het oorspronkelijke domein en de methode, zodat er geen verdere regels worden geëvalueerd. De header is echter niet toegestaan door de tweede regel, dus de aanvraag mislukt, ondanks het feit dat de semantiek van de derde regel zou hebben x-ms-client-request-id toegestaan.

Notitie

Hoewel in dit voorbeeld een minder beperkende regel vóór een meer beperkende regel wordt weergegeven, is het best practice om eerst de meest beperkende regels weer te geven.

Begrijpen hoe de Vary-header is ingesteld

De header is een standaard HTTP/1.1-header die bestaat uit een set aanvraagheadervelden die de browser of gebruikersagent adviseren over de criteria die door de server zijn geselecteerd om de aanvraag te Vary verwerken. De Vary header wordt hoofdzakelijk gebruikt voor caching door -proxies, browsers en CDN's, die deze gebruiken om te bepalen hoe het antwoord in de cache moet worden opgeslagen. Zie de specificatie van de Vary-header voor meer informatie.

Wanneer de browser of een andere gebruikersagent het antwoord van een CORS-aanvraag in de cache opgeslagen, wordt het oorspronkelijke domein in de cache opgeslagen als de toegestane oorsprong. Wanneer een tweede domein dezelfde aanvraag voor een opslagresource indient terwijl de cache actief is, haalt de gebruikersagent het oorspronkelijke domein op dat in de cache is opgeslagen. Het tweede domein komt niet overeen met het domein in de cache, dus de aanvraag mislukt wanneer dit anders zou lukken. In bepaalde gevallen stelt Azure Storage header in op om de gebruikersagent te instrueren de volgende CORS-aanvraag naar de service te verzenden wanneer het aanvragende domein verschilt van de oorsprong in de Vary Origin cache.

Azure Storage in de volgende gevallen de header in op Vary Origin voor werkelijke GET/HEAD-aanvragen:

  • Wanneer de oorsprong van de aanvraag exact overeenkomt met de toegestane oorsprong die is gedefinieerd door een CORS-regel. Om exact overeen te komen, bevat de CORS-regel mogelijk geen jokerteken '*'.

  • Er is geen regel die overeenkomt met de oorsprong van de aanvraag, maar CORS is ingeschakeld voor de opslagservice.

In het geval dat een GET/HEAD-aanvraag overeenkomt met een CORS-regel die alle oorsprongen toestaat, geeft het antwoord aan dat alle oorsprongen zijn toegestaan en staat de gebruikersagentcache volgende aanvragen van elk oorsprongdomein toe terwijl de cache actief is.

Houd er rekening mee dat voor aanvragen met andere methoden dan GET/HEAD de header niet wordt ingesteld door de opslagservices, omdat reacties op deze methoden niet door gebruikersagents in Vary de cache worden opgeslagen.

In de volgende tabel wordt aangegeven hoe Azure Storage reageert op GET/HEAD-aanvragen op basis van de eerder genoemde gevallen:

Origin-header aanwezig op aanvraag CORS-regel(s) die zijn opgegeven voor deze service Er bestaat een overeenkomende regel die alle oorsprongen toestaat ( * ) Er bestaat een overeenkomende regel voor exacte overeenkomst met de oorsprong Antwoord bevat de header Vary die is ingesteld op Origin Het antwoord omvat Access-Control-Allowed-Origin: " * " Het antwoord omvat Access-Control-Exposed-Headers
Nee Nee Nee Nee Nee Nee Nee
Nee Ja Nee Nee Ja Nee Nee
Nee Ja Ja Nee Nee Ja Ja
Ja Nee Nee Nee Nee Nee Nee
Ja Ja Nee Ja Ja Nee Ja
Ja Ja Nee Nee Ja Nee Nee
Ja Ja Ja Nee Nee Ja Ja

Facturering voor CORS-aanvragen

Geslaagde preflight-aanvragen worden gefactureerd als u CORS hebt ingeschakeld voor een van de opslagservices voor uw account (door Eigenschappen van Blob-serviceinstellen, Eigenschappenvan wachtrijservice instellen, Eigenschappenvan bestandsservice instellen of Table Service-eigenschappeninstellen) aan te roepen. Als u kosten wilt minimaliseren, kunt u het element in uw CORS-regels instellen op een grote waarde, zodat de gebruikeragent MaxAgeInSeconds de aanvraag in de cache opgeslagen.

Mislukte, voorlopige aanvragen worden niet gefactureerd.

Zie ook

W3C Cross-Origin Resource Sharing Specification