Eltérő eredetű erőforrások megosztásának (CORS) támogatása az Azure Storage-hoz

  • Cikk

A 2013-08-15-ös verziótól kezdődően az Azure Storage-szolgáltatások támogatják az eltérő eredetű erőforrások megosztását (CORS) a Blob-, Table- és Queue-szolgáltatásokhoz. A Fájlszolgáltatás a CORS-t a 2015-02-21-es verziótól kezdve támogatja.

A CORS egy olyan HTTP-szolgáltatás, amely egy adott tartományban futó webalkalmazás számára teszi lehetővé, hogy hozzáférjen egy másik tartomány erőforrásaihoz. A webböngészők olyan biztonsági korlátozást implementálnak , amelyet azonos eredetű szabályzatnak neveznek, amely megakadályozza, hogy egy weblap api-kat hívjon meg egy másik tartományban; A CORS biztonságos módot biztosít arra, hogy az egyik tartomány (a forrástartomány) meghívja az API-kat egy másik tartományban. A CORS-ról további információt a CORS specifikációjában talál.

A CORS-szabályokat az egyes Azure Storage-szolgáltatásokhoz külön-külön is beállíthatja, ha meghívja a Blobszolgáltatás tulajdonságainak beállítása, a Fájlszolgáltatás tulajdonságainak beállítása, a Várólista-szolgáltatás tulajdonságainak beállítása és a Táblaszolgáltatás tulajdonságainak megadása parancsot. Miután beállította az szolgáltatásra vonatkozó CORS-szabályokat, a rendszer megvizsgálja a más tartományból a szolgáltatás felé irányuló, megfelelő engedélyekkel rendelkező kéréseket, hogy megállapítsa, engedélyezettek-e a megadott szabályok alapján.

Fontos

A CORS nem engedélyezési mechanizmus. A CORS engedélyezésekor a tárolóerőforrásra irányuló kéréseknek érvényes engedélyezési fejléccel kell rendelkezniük, vagy nyilvános erőforráson kell elvégezniük.

A CORS minden tárfióktípus esetében támogatott, kivéve az általános célú v1- vagy v2-tárfiókokat a prémium szintű teljesítményszinten.

A CORS-kérelmek ismertetése

A forrástartományból érkező CORS-kérések két különálló kérésből állhatnak:

  • Egy előzetes kérés, amely lekérdezi a szolgáltatás által előírt CORS-korlátozásokat. Az elővizsgálati kérelemre csak akkor van szükség, ha a kérelemmetódus egyszerű metódus, azaz GET, HEAD vagy POST.

  • A kívánt erőforrásra irányuló tényleges kérés.

Előzetes kérés

Az elővizsgálati kérés lekérdezi a fióktulajdonos által a társzolgáltatásra vonatkozóan megállapított CORS-korlátozásokat. A webböngésző (vagy más felhasználói ügynök) egy OPTIONS kérést küld, amely tartalmazza a kérelem fejléceit, a metódust és a forrástartományt. A tárolási szolgáltatás a kívánt műveletet a CORS-szabályok előre konfigurált készlete alapján értékeli ki, amelyek meghatározzák, hogy mely forrástartományok, kérelemmetególok és kérelemfejlécek adhatók meg egy tárolási erőforrásra irányuló tényleges kérelemben.

Ha a CORS engedélyezve van a szolgáltatáshoz, és van egy CORS-szabály, amely megfelel az előzetes kérésnek, a szolgáltatás a 200 -os állapotkóddal (OK) válaszol, és tartalmazza a szükséges Access-Control fejléceket a válaszban.

Ha a CORS nincs engedélyezve a szolgáltatásban, vagy egyetlen CORS-szabály sem felel meg az előzetes kérésnek, a szolgáltatás a 403-at (Tiltott) állapotkóddal válaszolja meg.

Ha az OPTIONS kérés nem tartalmazza a szükséges CORS-fejléceket (az Origin és a Access-Control-Request-Method fejléceket), a szolgáltatás a 400 -os állapotkóddal válaszol (Hibás kérés).

Vegye figyelembe, hogy az előzetes kérések kiértékelése nem a kért erőforráson, hanem a szolgáltatáson (blob, fájl, üzenetsor vagy tábla) történik. A fiók tulajdonosának engedélyeznie kell a CORS-t a megfelelő fiókszolgáltatás-tulajdonságok beállításával, hogy a kérés sikeres legyen.

Tényleges kérelem

Az előzetes kérés elfogadása és a válasz visszaadása után a böngésző elküldi a tényleges kérést a tárolási erőforrásnak. A böngésző azonnal megtagadja a tényleges kérést, ha az előzetes kérést elutasítják.

A tényleges kérést normál kérésként kezeli a társzolgáltatás. A Forrás fejléc jelenléte azt jelzi, hogy a kérés CORS-kérelem, és a szolgáltatás ellenőrzi az egyező CORS-szabályokat. Ha talál egyezést, a rendszer hozzáadja a Access-Control fejléceket a válaszhoz, és visszaküldi az ügyfélnek. Ha nem talál egyezést, a CORS Access-Control fejlécek nem lesznek visszaadva.

A CORS engedélyezése az Azure Storage-hoz

A CORS-szabályok szolgáltatásszinten vannak beállítva, ezért minden szolgáltatáshoz (blob, fájl, üzenetsor és tábla) külön kell engedélyeznie vagy letiltania a CORS-t. Alapértelmezés szerint a CORS minden szolgáltatásban le van tiltva. A CORS engedélyezéséhez a 2013-08-15-es vagy újabb verzióval kell beállítania a megfelelő szolgáltatástulajdonságokat a Blob-, Queue- és Table-szolgáltatásokhoz, illetve a 2015-02-21-es vagy a Fájlszolgáltatáshoz. A CORS engedélyezéséhez adjon HOZZÁ CORS-szabályokat a szolgáltatás tulajdonságaihoz. A CORS szolgáltatáshoz való engedélyezéséről és letiltásáról, valamint a CORS-szabályok beállításáról a Blobszolgáltatás tulajdonságainak beállítása, a Fájlszolgáltatás tulajdonságainak megadása, a Táblaszolgáltatás tulajdonságainak megadása és a Várólista-szolgáltatás tulajdonságainak megadása című témakörben talál további információt.

Íme egy példa egyetlen CORS-szabályra, amely egy művelettel van Set Service Properties megadva:

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

A CORS-szabály minden elemét az alábbiakban ismertetjük:

  • AllowedOrigins: Azok a forrástartományok, amelyek a CORS-on keresztül kérést kezdeményezhetnek a tárolási szolgáltatással szemben. A forrástartomány az a tartomány, ahonnan a kérelem származik. Vegye figyelembe, hogy a forrásnak pontosan meg kell egyeznie a felhasználó életkora által a szolgáltatásnak küldött forrással.

    A megadott tartomány helyett használhatja a "*" helyettesítő karaktert, hogy az összes forrástartomány kéréseket küldjön a CORS-on keresztül. Az altartomány helyett a helyettesítő karaktert is használhatja, hogy egy adott tartomány összes altartománya kérvényeket küldjön a CORS-on keresztül. A fenti példában az összes altartománya contoso.com a CORS-on keresztül tud kéréseket küldeni, míg a CORS-on keresztül csak az www altartományból fabrikam.com érkező kérések engedélyezettek.

  • AllowedMethods: Azok a metódusok (HTTP-kérési műveletek), amelyeket a forrástartomány a CORS-kérelmekhez használhat. A fenti példában csak a PUT és a GET kérések engedélyezettek.

  • AllowedHeaders: Azok a kérésfejlécek, amelyeket a forrástartomány megadhat a CORS-kérelemben. A fenti példában minden metaadatfejléc , és x-ms-meta-targetx-ms-meta-abc kezdetű x-ms-meta-datametaadat-fejléc engedélyezett. Vegye figyelembe, hogy a "*" helyettesítő karakter azt jelzi, hogy a megadott előtaggal kezdődő fejlécek engedélyezettek.

  • ExposedHeaders: A CORS-kérelemre adott válaszban elküldhető és a böngésző által a kérés kiállítójának közzétett válaszfejlécek. A fenti példában a böngésző arra utasítja a böngészőt, hogy tegye közzé a fejlécet a következővel kezdődően x-ms-meta: .

  • MaxAgeInSeconds: Az a maximális időtartam, amellyel a böngészőnek gyorsítótáraznia kell az előzetes beállítások kérését.

Az Azure Storage-szolgáltatások támogatják az előtagú fejlécek megadását az AllowedHeaders és az ExposedHeaders elemekhez is. A fejlécek kategóriájának engedélyezéséhez megadhat egy közös előtagot az adott kategóriához. Az előtagként megadott x-ms-meta* fejléc például létrehoz egy szabályt, amely megfelel az összes fejlécnek, amely a következővel x-ms-metakezdődik: .

A CORS-szabályokra a következő korlátozások vonatkoznak:

  • Tárolási szolgáltatásonként legfeljebb öt CORS-szabályt adhat meg (blob, fájl, tábla és üzenetsor).

  • A kérelem összes CORS-szabálybeállításának maximális mérete – az XML-címkék kivételével – nem haladhatja meg a 2 KiB-t.

  • Az engedélyezett fejléc, a közzétett fejléc vagy az engedélyezett forrás hossza nem haladhatja meg a 256 karaktert.

  • Az engedélyezett fejlécek és a közzétett fejlécek a következők lehetnek:

    • Literál fejlécek, ahol a pontos fejlécnév szerepel, például x-ms-meta-processed. A kérelemben legfeljebb 64 literális fejléc adható meg.
    • Előtaggal rendelkező fejlécek, ahol meg van adva a fejléc előtagja, például x-ms-meta-data*. Az előtag ilyen módon történő megadása lehetővé teszi vagy elérhetővé teszi az adott előtaggal kezdődő fejléceket. A kérelemben legfeljebb két előtagú fejléc adható meg.

  • Az AllowedMethods elemben megadott metódusoknak (vagy HTTP-parancsoknak) meg kell felelniük az Azure Storage szolgáltatás API-jai által támogatott metódusoknak. A támogatott módszerek a KÖVETKEZŐK: DELETE, GET, HEAD, MERGE, POST, PATCH, OPTIONS és PUT.

A CORS-szabály kiértékelési logikája

Amikor egy tárolási szolgáltatás előzetes vagy tényleges kérést kap, a megfelelő Szolgáltatástulajdonságok beállítása művelettel kiértékeli a kérést a szolgáltatáshoz létrehozott CORS-szabályok alapján. A CORS-szabályok kiértékelése abban a sorrendben történik, amelyben be lettek állítva a Szolgáltatás tulajdonságainak beállítása művelet kérelemtörzsében.

A CORS-szabályok kiértékelése az alábbiak szerint történik:

  1. Először a kérelem forrástartományát a rendszer összeveti az elemhez AllowedOrigins felsorolt tartományokkal. Ha a forrástartomány szerepel a listában, vagy az összes tartomány engedélyezett a "*" helyettesítő karakterrel, akkor a szabályok kiértékelése folytatódik. Ha a forrástartomány nem szerepel a fájlban, a kérés sikertelen lesz.

  2. Ezután a rendszer ellenőrzi a kérés metódusát (vagy HTTP-parancsát) az elemben AllowedMethods felsorolt metódusok között. Ha a metódus szerepel a listában, a szabályok kiértékelése folytatódik; ha nem, akkor a kérés meghiúsul.

  3. Ha a kérelem megfelel egy szabálynak a forrástartományában és a metódusában, akkor a rendszer ezt a szabályt választja a kérelem feldolgozásához, és nincs további szabály kiértékelése. A kérés sikeres végrehajtása előtt azonban a kérelemben megadott fejléceket a rendszer összeveti az AllowedHeaders elemben felsorolt fejlécekkel. Ha az elküldött fejlécek nem felelnek meg az engedélyezett fejléceknek, a kérés meghiúsul.

Mivel a szabályok feldolgozása a kérelem törzsében található sorrendben történik, az ajánlott eljárások azt javasolják, hogy a lista elején adja meg a legszigorúbb szabályokat a forrásokkal kapcsolatban, hogy a rendszer először kiértékelje őket. A lista végén adja meg a kevésbé korlátozó szabályokat – például az összes forrást engedélyező szabályt.

Példa – CORS-szabályok kiértékelése

Az alábbi példa egy részleges kérelemtörzset mutat be egy olyan művelethez, amely CORS-szabályokat állít be a tárolási szolgáltatásokhoz. A kérés felépítésének részleteiért lásd: Blobszolgáltatás tulajdonságainak beállítása, Fájlszolgáltatás tulajdonságainak beállítása, Üzenetsor-szolgáltatás tulajdonságainak beállítása és Táblaszolgáltatás tulajdonságainak beállítása .

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

Ezután vegye figyelembe a következő CORS-kéréseket:

Metódus Forrás Kérésfejlécek Szabályegyezés Eredmény
PUT http://www.contoso.com x-ms-blob-content-type Első szabály Siker
GET http://www.contoso.com x-ms-blob-content-type Második szabály Siker
GET http://www.contoso.com x-ms-client-request-id Második szabály Hiba

Az első kérés megfelel az első szabálynak – a forrástartomány megfelel az engedélyezett forrásoknak, a metódusnak az engedélyezett metódusoknak, a fejléc pedig az engedélyezett fejléceknek – és így sikeres lesz.

A második kérés nem felel meg az első szabálynak, mert a metódus nem felel meg az engedélyezett metódusnak. Ez azonban megfelel a második szabálynak, így sikeres lesz.

A harmadik kérés megegyezik a forrástartomány második szabályával és metódusával, így a rendszer nem értékeli ki a további szabályokat. x-ms-client-request-id A fejlécet azonban nem engedélyezi a második szabály, így a kérés meghiúsul annak ellenére, hogy a harmadik szabály szemantikája lehetővé tette volna a sikerességét.

Megjegyzés

Bár ez a példa egy kevésbé korlátozó szabályt mutat be egy szigorúbb előtt, általában az ajánlott eljárás a legszigorúbb szabályok felsorolása.

A Vary fejléc beállításának ismertetése

A Vary fejléc egy szabványos HTTP/1.1-fejléc, amely kérelemfejlécmezők készletéből áll, amelyek tájékoztatják a böngészőt vagy a felhasználói ügynököt a kérés feldolgozásához a kiszolgáló által kiválasztott feltételekről. A Vary fejlécet főként proxyk, böngészők és CDN-k gyorsítótárazására használják, amelyek a válasz gyorsítótárazásának meghatározására használják. Részletekért tekintse meg a Vary fejléc specifikációját.

Amikor a böngésző vagy egy másik felhasználói ügynök gyorsítótárazza a CORS-kérés válaszát, a forrástartomány lesz gyorsítótárazva engedélyezett forrásként. Ha egy második tartomány ugyanazt a kérést küldi ki egy tárolási erőforrásra vonatkozóan, amíg a gyorsítótár aktív, a felhasználói ügynök lekéri a gyorsítótárazott forrástartományt. A második tartomány nem egyezik a gyorsítótárazott tartománnyal, ezért a kérés meghiúsul, ha egyébként sikeres lenne. Bizonyos esetekben az Azure Storage úgy állítja be a Vary fejlécet, hogy Origin utasítsa a felhasználói ügynököt, hogy küldje el a következő CORS-kérést a szolgáltatásnak, ha a kérelmező tartomány eltér a gyorsítótárazott forrástól.

Az Azure Storage a következő esetekben állítja be a Vary fejlécet Origin a tényleges GET/HEAD kérésekhez:

  • Ha a kérelem eredete pontosan megegyezik a CORS-szabály által meghatározott engedélyezett forrással. A pontos egyezés érdekében előfordulhat, hogy a CORS-szabály nem tartalmaz "*" helyettesítő karaktert.

  • Nincs a kérés forrásának megfelelő szabály, de a CORS engedélyezve van a tárolási szolgáltatásban.

Abban az esetben, ha egy GET/HEAD kérés megfelel az összes forrást engedélyező CORS-szabálynak, a válasz azt jelzi, hogy az összes forrás engedélyezett, és a felhasználói ügynök gyorsítótára engedélyezi a további kéréseket bármely forrástartományból, amíg a gyorsítótár aktív.

Vegye figyelembe, hogy a GET/HEAD metódustól eltérő metódusokat használó kérések esetében a tárolási szolgáltatások nem állítják be a Vary fejlécet, mivel az ezekre a metódusokra adott válaszokat a felhasználói ügynökök nem gyorsítótárazják.

Az alábbi táblázat azt mutatja be, hogy az Azure Storage hogyan válaszol a GET/HEAD kérelmekre a korábban említett esetek alapján:

A kérelemben található forrásfejléc A szolgáltatáshoz megadott CORS-szabály(ok) Létezik egyező szabály, amely minden forrást engedélyez (*) A pontos forrásegyeztetéshez létezik egyező szabály A válasz tartalmazza a Különböző fejlécek forrás értékre van állítva A válasz tartalmazza a hozzáférés-vezérlés engedélyezett forrását: "*" A válasz tartalmazza az Access-Control-Exposed-Headers parancsot
Nem Nem Nem Nem Nem Nem Nem
Nem Igen Nem Nem Igen Nem Nem
Nem Igen Igen Nem Nem Igen Igen
Igen Nem Nem Nem Nem Nem Nem
Igen Igen Nem Igen Igen Nem Igen
Igen Igen Nem Nem Igen Nem Nem
Igen Igen Igen Nem Nem Igen Yes

CORS-kérelmek számlázása

A sikeres elővizsgálati kérések számlázása akkor történik, ha engedélyezte a CORS-t a fiókjához tartozó bármelyik tárolási szolgáltatáshoz (a Blobszolgáltatás tulajdonságainak beállítása, a Várólista-szolgáltatás tulajdonságainak megadása, a Fájlszolgáltatás tulajdonságainak megadása vagy a Táblaszolgáltatás tulajdonságainak beállítása meghívásával). A díjak minimalizálása érdekében fontolja meg a MaxAgeInSeconds CORS-szabályok elemének nagy értékre állítását, hogy a felhasználói ügynök gyorsítótárazza a kérést.

A sikertelen elővizsgálati kérések nem lesznek számlázva.

Lásd még

A W3C eltérő eredetű erőforrás-megosztási specifikációja