Delen via

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

  • Artikel

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

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 in een ander domein aanroept; CORS biedt een veilige manier om toe te staan dat één domein (het oorspronkelijke domein) API's in een ander domein aanroept. 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 blobservice instellen, Eigenschappen van bestandsservice instellen, Eigenschappen van wachtrijservice instellen en Eigenschappen van tabelservice instellen aan 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 gedaan voor een opslagresource wanneer CORS is ingeschakeld, moet een geldige autorisatieheader hebben of moeten worden gedaan op basis van een openbare resource.

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

CORS-aanvragen begrijpen

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

  • Een voorbereidende aanvraag, waarmee de CORS-beperkingen worden opgevraagd die door de service zijn opgelegd. De voorbereidende aanvraag is vereist, tenzij de aanvraagmethode een eenvoudige methode is, dat wil zeggen GET, HEAD of POST.

  • De werkelijke aanvraag, gemaakt op basis van de gewenste resource.

Voorbereidende aanvraag

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

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

Als CORS niet is ingeschakeld voor de service of als er geen CORS-regel overeenkomt met de voorbereidende 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 (Ongeldige aanvraag).

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

Werkelijke aanvraag

Zodra de voorbereidende aanvraag is geaccepteerd en het antwoord is geretourneerd, verzendt de browser de werkelijke aanvraag naar de opslagresource. De browser weigert de werkelijke aanvraag onmiddellijk als de voorbereidende aanvraag wordt geweigerd.

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 de 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 voor elke service (Blob, Bestand, Wachtrij en Tabel) afzonderlijk in- of uitschakelen. 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 schakelt CORS in 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 blobservice instellen, Eigenschappen van bestandsservice instellen, Eigenschappen van tabelservice instellen en Eigenschappen van wachtrijservice instellen.

Hier volgt 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 in de CORS-regel is opgenomen, wordt hieronder beschreven:

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

    U kunt het jokerteken '*' gebruiken in plaats van een opgegeven domein om alle oorspronkelijke domeinen toe te staan aanvragen te doen via CORS. U kunt ook het jokerteken in plaats van een subdomein gebruiken om alle subdomeinen van een bepaald domein toe te staan aanvragen te doen via CORS. In het bovenstaande voorbeeld kunnen alle subdomeinen van contoso.com aanvragen doen via CORS, terwijl alleen aanvragen van het www subdomein van fabrikam.com zijn toegestaan via 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 met x-ms-meta-data, x-ms-meta-targeten x-ms-meta-abc toegestaan. Houd er rekening mee dat het jokerteken *aangeeft dat elke koptekst die begint met het opgegeven voorvoegsel is toegestaan.

  • ExposedHeaders: de antwoordheaders die in het antwoord op de CORS-aanvraag kunnen worden verzonden en door de browser worden weergegeven aan de verlener van de aanvraag. In het bovenstaande voorbeeld wordt de browser geïnstrueerd om elke header weer te geven die begint met x-ms-meta.

  • MaxAgeInSeconds: de maximale hoeveelheid tijd dat een browser de voorbereidende OPTIONS-aanvraag in de cache moet opslaan.

De Azure-opslagservices bieden ondersteuning voor het opgeven van voorvoegsels voor de elementen AllowedHeaders en ExposedHeaders . Als u een categorie kopteksten wilt toestaan, kunt u een gemeenschappelijk voorvoegsel voor die categorie opgeven. Als u bijvoorbeeld opgeeft x-ms-meta* als een voorvoegsel koptekst, wordt een regel tot stand gebracht die overeenkomt met alle headers die beginnen met x-ms-meta.

De volgende beperkingen zijn van toepassing op CORS-regels:

  • U kunt maximaal vijf CORS-regels per opslagservice opgeven (blob, bestand, tabel en wachtrij).

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

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

  • Toegestane headers en weergegeven headers kunnen 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.
    • Voorvoegselkoppen, waarbij een voorvoegsel van de header wordt opgegeven, zoals x-ms-meta-data*. Als u op deze manier een voorvoegsel opgeeft, wordt elke koptekst die begint met het opgegeven voorvoegsel, toegestaan of weergegeven. Er kunnen maximaal twee voorvoegsels 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 Azure Storage Service-API's. Ondersteunde methoden zijn DELETE, GET, HEAD, MERGE, POST, PATCH, OPTIONS en PUT.

Inzicht in de evaluatielogica van CORS-regels

Wanneer een opslagservice een voorbereidende of werkelijke 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 aanvraagtekst van de bewerking Service-eigenschappen instellen.

CORS-regels worden als volgt geëvalueerd:

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

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

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

Aangezien de regels worden verwerkt in de volgorde waarin ze aanwezig zijn in de aanvraagbody, wordt aanbevolen dat u de meest beperkende regels met betrekking tot oorsprongen als eerste in de lijst opgeeft, zodat deze eerst worden geëvalueerd. Geef aan het einde van de lijst regels op die minder beperkend zijn, bijvoorbeeld een regel om alle origins toe te staan.

Voorbeeld: CORS-regels evalueren

In het volgende voorbeeld ziet u een gedeeltelijke aanvraagbody voor een bewerking om CORS-regels in te stellen voor de opslagservices. Zie Eigenschappen van blobservice instellen, Eigenschappen van bestandsservice instellen, Eigenschappen van wachtrijservice instellen en Eigenschappen van tabelservice instellen voor meer informatie over het samenstellen 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 Regelovereenkomst Resultaat
PUT http://www.contoso.com x-ms-blob-content-type Eerste regel Geslaagd
GET http://www.contoso.com x-ms-blob-content-type Tweede regel Geslaagd
GET 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 origins, 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 overeenkomt met de toegestane methoden. Het komt echter wel overeen met de tweede regel, dus het 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 x-ms-client-request-id header is echter niet toegestaan door de tweede regel, dus de aanvraag mislukt, ondanks het feit dat de semantiek van de derde regel deze zou hebben toegestaan.

Notitie

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

Informatie over hoe de Vary-header is ingesteld

De Vary 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 verwerken. De Vary header wordt voornamelijk gebruikt voor het opslaan in cache door proxy's, browsers en CDN's, die deze gebruiken om te bepalen hoe het antwoord in de cache moet worden opgeslagen. Zie de specificatie voor de header Vary voor meer informatie.

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

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

  • Wanneer de oorsprong van de aanvraag exact overeenkomt met de toegestane oorsprong die is gedefinieerd door een CORS-regel. De CORS-regel mag geen jokerteken '*' bevatten.

  • 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 origins toestaat, geeft het antwoord aan dat alle origins zijn toegestaan en dat de cache van de gebruikersagent volgende aanvragen van elk origin-domein toestaat terwijl de cache actief is.

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

De volgende tabel geeft aan hoe Azure Storage reageert op GET/HEAD-aanvragen op basis van de eerder genoemde cases:

Oorsprongheader aanwezig op aanvraag CORS-regel(en) die zijn opgegeven voor deze service Er bestaat een overeenkomende regel die alle oorsprongen (*) toestaat Er bestaat een overeenkomende regel voor exacte oorsprongovereenkomst Antwoord bevat de Vary-header ingesteld op Origin Het antwoord bevat Access-Control-Allowed-Origin: "*" Het antwoord bevat 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 voorbereidende aanvragen worden gefactureerd als u CORS hebt ingeschakeld voor een van de opslagservices voor uw account (door Eigenschappen van blobservice instellen, Eigenschappen van wachtrijservice instellen, Eigenschappen van bestandsservice instellen of Tabelservice-eigenschappen instellen aan te roepen). Als u de kosten wilt minimaliseren, kunt u overwegen om het MaxAgeInSeconds element in uw CORS-regels in te stellen op een grote waarde, zodat de gebruikersagent de aanvraag in de cache opslaat.

Mislukte voorbereidende aanvragen worden niet gefactureerd.

Zie ook

W3C Cross-Origin Resource Sharing Specification