Engedélyezés megosztott kulccsal

  • Cikk

A tárolási szolgáltatásra irányuló minden kérést engedélyezni kell, kivéve, ha a kérés nyilvános vagy aláírt hozzáféréshez elérhetővé tett blob- vagy tárolóerőforrásra érvényes. A kérések engedélyezésének egyik lehetősége a megosztott kulcs használata, amelyről ebben a cikkben olvashat.

Tipp

Az Azure Storage integrációt biztosít a Microsoft Entra ID a Blob-, File-, Queue- és Table-szolgáltatások felé irányuló kérések identitásalapú engedélyezéséhez. A Microsoft Entra ID szerepköralapú hozzáférés-vezérléssel (RBAC) biztosíthat hozzáférést a blob-, fájl-, üzenetsor- és táblaerőforrásokhoz a felhasználók, csoportok vagy alkalmazások számára. Microsoft Entra ID használhatja a tárerőforrásokhoz való hozzáférés engedélyezését anélkül, hogy a fiók hozzáférési kulcsait az alkalmazásaiban tárolhatja, ahogyan a megosztott kulccsal tenné. További információ: Engedélyezés Microsoft Entra ID.

A Blob, a Queue, a Table és a File szolgáltatás a következő megosztottkulcs-engedélyezési sémákat támogatja a 2009-09-19-es és újabb verziókhoz (Blob, Queue és Table szolgáltatáshoz), valamint a 2014-02-14-es és újabb verziókhoz (a Fájlszolgáltatás esetében):

  • Megosztott kulcs blobokhoz, üzenetsorokhoz és fájlszolgáltatásokhoz. A Megosztott kulcs engedélyezési sémával kéréseket kezdeményezhet a blob-, üzenetsor- és fájlszolgáltatásokra. A megosztott kulcs engedélyezése a 2009-09-19-es és újabb verziókban támogatja a kibővített aláírási sztringet a fokozott biztonság érdekében, és megköveteli, hogy frissítse a szolgáltatást, hogy engedélyezze ezt a kibővített aláírást.

  • A Table Service megosztott kulcsa. A Megosztott kulcs engedélyezési sémával kéréseket intézhet a Table szolgáltatáshoz a REST API használatával. A Table szolgáltatás megosztott kulcsának engedélyezése a 2009-09-19-es és újabb verziókban ugyanazt az aláírási sztringet használja, mint a Table szolgáltatás korábbi verzióiban.

  • Megosztott kulcs Lite. A Megosztott kulcs Lite engedélyezési sémával kéréseket kezdeményezhet a Blob, a Queue, a Table és a File szolgáltatásokra.

    A Blob- és Queue-szolgáltatások 2009-09-19-es és újabb verziói esetében a Megosztott kulcs Lite-engedélyezés támogatja a Megosztott kulcs szolgáltatás korábbi verzióiban támogatott aláírási sztring használatát. Ezért a Shared Key Lite használatával kéréseket intézhet a Blob- és Queue-szolgáltatásokhoz az aláírási sztring frissítése nélkül.

Egy engedélyezett kérelemhez két fejlécre van szükség: a vagy fejlécre Date és a fejlécreAuthorization.x-ms-date A következő szakaszok ismertetik, hogyan hozhatja létre ezeket a fejléceket.

Fontos

Az Azure Storage támogatja a HTTP-t és a HTTPS-t is, de a HTTPS használata erősen ajánlott.

Megjegyzés

A tárolók vagy blobok nyilvános hozzáférésre is elérhetővé tehetők egy tároló engedélyeinek beállításával. További információ: Az Azure Storage-erőforrásokhoz való hozzáférés kezelése. A tárolók, blobok, üzenetsorok vagy táblák elérhetővé tehetők aláírt hozzáféréshez közös hozzáférésű jogosultságkóddal; a közös hozzáférésű jogosultságkód egy másik mechanizmuson keresztül van engedélyezve. További részletekért lásd: Hozzáférés delegálása közös hozzáférésű jogosultságkóddal .

A Dátum fejléc megadása

Minden engedélyezett kérésnek tartalmaznia kell a kérelem utc-időbélyegét. Az időbélyeget a fejlécben vagy a x-ms-date szabványos HTTP/HTTPS-fejlécben Date adhatja meg. Ha mindkét fejléc meg van adva a kérelemben, a rendszer a kérelem létrehozási idejeként az értékét x-ms-date használja.

A tárolási szolgáltatások biztosítják, hogy a kérések a szolgáltatás eléréséig ne legyenek 15 percnél régebbiek. Ez védelmet nyújt bizonyos biztonsági támadások ellen, beleértve a visszajátszásos támadásokat is. Ha ez az ellenőrzés sikertelen, a kiszolgáló a 403-at (Tiltott) válaszkódot adja vissza.

Megjegyzés

A x-ms-date fejléc azért van megadva, mert egyes HTTP-ügyfélkódtárak és proxyk automatikusan beállítják a Date fejlécet, és nem adnak lehetőséget a fejlesztőnek arra, hogy elolvassa az értékét, hogy belefoglalja az engedélyezett kérelembe. Ha be van állítva x-ms-date, hozza létre az aláírást a fejléc üres értékével Date .

Az Engedélyezési fejléc megadása

Az engedélyezett kérésnek tartalmaznia kell a fejlécet Authorization . Ha ez a fejléc nem szerepel a fejlécben, a kérés névtelen, és csak nyilvános hozzáférésre megjelölt tárolón vagy blobon, illetve olyan tárolón, blobon, üzenetsoron vagy táblán sikeres, amelyhez megosztott hozzáférés-aláírást adtak meg a delegált hozzáféréshez.

A kérés engedélyezéséhez alá kell írnia a kérést a kérelmet küldő fiók kulcsával, és a kérés részeként át kell adnia az aláírást.

A fejléc formátuma Authorization a következő:

Authorization="[SharedKey|SharedKeyLite] <AccountName>:<Signature>"

where SharedKey or SharedKeyLite is the name of the authorization scheme, is the name of the account requesting the resource, AccountName and Signature is a hash-based Message Authentication Code (HMAC) a kérésből létrehozott és az SHA256 algoritmussal kiszámított, majd Base64 kódolással kódolt fiók neve.

Megjegyzés

Ha az erőforrás nyilvánosan elérhető, kérhet egy másik fiók alatt található erőforrást.

A következő szakaszok a fejléc felépítését Authorization írják le.

Az aláírási sztring létrehozása

Az aláírási sztring létrehozásának menete attól függ, hogy melyik szolgáltatást és verziót engedélyezi, és melyik engedélyezési sémát használja. Az aláírási sztring létrehozásakor tartsa szem előtt a következőket:

  • A sztring VERB része a HTTP-parancs, például GET vagy PUT, és nagybetűsnek kell lennie.

  • A blob-, üzenetsor- és fájlszolgáltatások megosztottkulcs-engedélyezése esetén az aláírási sztringben szereplő összes fejléc csak egyszer jelenhet meg. Ha valamelyik fejléc duplikálva van, a szolgáltatás a 400-ás állapotkódot adja vissza (hibás kérés).

  • Az összes szabványos HTTP-fejléc értékét az aláírási formátumban megjelenített sorrendben, fejlécnevek nélkül kell szerepeltetni a sztringben. Ezek a fejlécek üresek lehetnek, ha nincsenek megadva a kérés részeként; ebben az esetben csak az új sor karakterre van szükség.

  • Ha a x-ms-date fejléc meg van adva, figyelmen kívül hagyhatja a Date fejlécet, függetlenül attól, hogy a kérelemben meg van-e adva, és egyszerűen megadhat egy üres sort az Date aláírási sztring részéhez. Ebben az esetben kövesse a canonicalizált fejlécek sztringjének összeállítása szakasz utasításait a x-ms-date fejléc hozzáadásához.

    Elfogadható mind a, Datemind x-ms-date a megadása; ebben az esetben a szolgáltatás a értékét x-ms-datehasználja.

  • Ha a x-ms-date fejléc nincs megadva, adja meg a Date fejlécet az aláírási sztringben a fejléc nevének megadása nélkül.

  • Az aláírási sztringben minden új sorkarakterek (\n) megadása kötelező.

  • Az aláírási sztring canonicalizált fejléceket és canonicalizált erőforrás-sztringeket tartalmaz. Ezeknek a sztringeknek a canonicalizálása az Azure Storage által felismert szabványos formátumba helyezi őket. Az aláírási CanonicalizedHeaders sztring részét képező és CanonicalizedResource sztringek felépítésével kapcsolatos részletes információkért tekintse meg a jelen témakör megfelelő szakaszait.

Blob-, üzenetsor- és fájlszolgáltatások (megosztott kulcs engedélyezése)

Ha a Blob vagy Queue szolgáltatás 2009-09-19-es és újabb verziójára, valamint a Fájlszolgáltatás 2014-02-14-es és újabb verziójára vonatkozó kérések közöskulcs-aláírási sztringjére szeretne kódolni, használja a következő formátumot:

StringToSign = VERB + "\n" +  
               Content-Encoding + "\n" +  
               Content-Language + "\n" +  
               Content-Length + "\n" +  
               Content-MD5 + "\n" +  
               Content-Type + "\n" +  
               Date + "\n" +  
               If-Modified-Since + "\n" +  
               If-Match + "\n" +  
               If-None-Match + "\n" +  
               If-Unmodified-Since + "\n" +  
               Range + "\n" +  
               CanonicalizedHeaders +   
               CanonicalizedResource;

Fontos

Az aktuális verzióban a Content-Length mezőnek üres sztringnek kell lennie, ha a kérés tartalomhossza nulla. A 2014-02-14-es és korábbi verziókban a tartalom hossza akkor is szerepelt, ha nulla. A régi viselkedésről az alábbiakban talál további információt.

Az alábbi példa a Blob lekérése művelethez tartozó aláírási sztringet mutatja be. Ha nincs fejlécérték, a rendszer csak az új sor karaktert adja meg.

GET\n\n\n\n\n\n\n\n\n\n\n\nx-ms-date:Fri, 26 Jun 2015 23:39:12 GMT\nx-ms-version:2015-02-21\n/myaccount/mycontainer\ncomp:metadata\nrestype:container\ntimeout:20

A sztring egyes részeit sorról sorra lebontva:

GET\n /*HTTP Verb*/  
\n    /*Content-Encoding*/  
\n    /*Content-Language*/  
\n    /*Content-Length (empty string when zero)*/  
\n    /*Content-MD5*/  
\n    /*Content-Type*/  
\n    /*Date*/  
\n    /*If-Modified-Since */  
\n    /*If-Match*/  
\n    /*If-None-Match*/  
\n    /*If-Unmodified-Since*/  
\n    /*Range*/  
x-ms-date:Fri, 26 Jun 2015 23:39:12 GMT\nx-ms-version:2015-02-21\n    /*CanonicalizedHeaders*/  
/myaccount /mycontainer\ncomp:metadata\nrestype:container\ntimeout:20    /*CanonicalizedResource*/

Ezután kódolja ezt a sztringet a HMAC-SHA256 algoritmussal az UTF-8 kódolású aláírási sztringen keresztül, hozza létre a Authorization fejlécet, és adja hozzá a fejlécet a kéréshez. Az alábbi példa ugyanannak a műveletnek a Authorization fejlécét mutatja be:

Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=

Ha a Blob- és Üzenetsor-szolgáltatások 2009-09-19-es és újabb verziójával szeretné használni a megosztott kulcsos hitelesítést, frissítenie kell a kódot, hogy ezt a kibővített aláírási sztringet használja.

Ha a blob- és üzenetsor-szolgáltatások 2009-09-19-es vagy újabb verziójára szeretné migrálni a kódot a lehető legkevesebb módosítással, módosíthatja a meglévő Authorization fejléceket úgy, hogy a Megosztott kulcs Lite-ot használják a Megosztott kulcs helyett. A Shared Key Lite által megkövetelt aláírási formátum megegyezik a Blob- és Queue-szolgáltatások 2009-09-19 előtti verziói által a megosztott kulcshoz szükséges aláírási formátummal.

Fontos

Ha olyan tárfiókban fér hozzá a másodlagos helyhez, amelyhez engedélyezve van az írásvédett georeplikáció (RA-GRS), ne foglalja bele a megjelölést az -secondary engedélyezési fejlécbe. Engedélyezési célokból a fióknév mindig az elsődleges hely neve, még másodlagos hozzáférés esetén is.

Content-Length fejléc a 2014-02-14-es és korábbi verzióban

Ha a 2014-02-14-es vagy korábbi verziót használja, ha Content-Length nulla, állítsa a Content-Length rész értékét értékre StringToSign0. Ez általában egy üres sztring lenne.

A következő kérés esetében például a Content-Length fejléc értéke akkor is szerepel a StringToSign fejlécben, ha az nulla.

PUT http://myaccount/mycontainer?restype=container&timeout=30 HTTP/1.1  
x-ms-version: 2014-02-14  
x-ms-date: Fri, 26 Jun 2015 23:39:12 GMT  
Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=  
Content-Length: 0

A StringToSign felépítése a következő:

Version 2014-02-14 and earlier:
PUT\n\n\n\n0\n\n\n\n\n\n\n\nx-ms-date:Fri, 26 Jun 2015 23:39:12 GMT\nx-ms-version:2014-02-14\n/myaccount/mycontainer\nrestype:container\ntimeout:30

Míg a 2014-02-14-et követő verziókban a StringToSign sztringnek üres sztringet kell tartalmaznia:Content-Length

Version 2015-02-21 and later:
PUT\n\n\n\n\n\n\n\n\n\n\n\nx-ms-date:Fri, 26 Jun 2015 23:39:12 GMT\nx-ms-version:2015-02-21\n/myaccount/mycontainer\nrestype:container\ntimeout:30

Table service (megosztott kulcs engedélyezése)

Ha a szolgáltatás a REST API-t használja a kérés teljesítéséhez, megosztott kulcsos hitelesítéssel kell engedélyeznie a Table szolgáltatásra irányuló kérést. A Table service-hez tartozó Megosztott kulcs aláírási sztringjének formátuma minden verzió esetében megegyezik.

A Table service-hez tartozó kérések közöskulcs-aláírási sztringje kissé eltér a Blob vagy a Queue szolgáltatásra irányuló kérésekétől, mivel nem tartalmazza a CanonicalizedHeaders sztring részét. Emellett a fejléc ebben az Date esetben soha nem üres, még akkor sem, ha a kérés beállítja a fejlécet x-ms-date . Ha a kérés beállítja x-ms-datea értéket, akkor a fejléc értékéhez is ezt az értéket használja a Date rendszer.

A REST API használatával létrehozott Table szolgáltatásra irányuló kérés aláírási sztringjének kódolásához használja a következő formátumot:

StringToSign = VERB + "\n" +
               Content-MD5 + "\n" +
               Content-Type + "\n" +  
               Date + "\n" +  
               CanonicalizedResource;

Megjegyzés

A Table szolgáltatásnak a 2009-09-19-es verziótól kezdődően minden REST-hívásnak tartalmaznia kell a és MaxDataServiceVersion a DataServiceVersion fejlécet. További információ : Az OData Data Service verziófejléceinek beállítása .

Blob-, üzenetsor- és fájlszolgáltatások (Shared Key Lite-hitelesítés)

A Shared Key Lite-hitelesítéssel engedélyezheti a Blob- és Queue-szolgáltatások 2009-09-19-es és újabb verzióira, valamint a Fájlszolgáltatások 2014-02-14-es és újabb verzióira irányuló kéréseket.

A Shared Key Lite aláírási sztringje megegyezik a Blob- és Queue-szolgáltatások 2009-09-19 előtti verzióiban a megosztott kulcs engedélyezéséhez szükséges aláírási sztringgel. Ha tehát a blob- és üzenetsor-szolgáltatások 2009-09-19-es verziójára szeretné migrálni a kódot a legkevesebb módosítással, módosíthatja a kódot a Megosztott kulcs Lite használatára anélkül, hogy magát az aláírási sztringet módosítaná. A Shared Key Lite használatával nem fogja megkapni a megosztott kulcs 2009-09-19-es és újabb verziójával biztosított fokozott biztonsági funkciókat.

A Blob vagy a Queue szolgáltatáshoz tartozó kérések aláírási sztringjének kódolásához használja a következő formátumot:

StringToSign = VERB + "\n" +  
               Content-MD5 + "\n" +  
               Content-Type + "\n" +  
               Date + "\n" +  
               CanonicalizedHeaders +   
               CanonicalizedResource;

Az alábbi példa egy Put Blob művelethez tartozó aláírási sztringet mutat be. Vegye figyelembe, hogy a Content-MD5 fejlécsor üres. A sztringben látható fejlécek név-érték párok, amelyek egyéni metaadat-értékeket adnak meg az új blobhoz.

PUT\n\ntext/plain; charset=UTF-8\n\nx-ms-date:Sun, 20 Sep 2009 20:36:40 GMT\nx-ms-meta-m1:v1\nx-ms-meta-m2:v2\n/testaccount1/mycontainer/hello.txt

Ezután kódolja ezt a sztringet a HMAC-SHA256 algoritmussal az UTF-8 kódolású aláírási sztringen keresztül, hozza létre a Authorization fejlécet, és adja hozzá a fejlécet a kéréshez. Az alábbi példa ugyanahhoz a Authorization művelethez tartozó fejlécet mutatja be:

Authorization: SharedKeyLite myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=

Table service (Shared Key Lite engedélyezés)

A Megosztott kulcs Lite-hitelesítéssel engedélyezheti a Table szolgáltatás bármely verziójára irányuló kérést.

A Table service-hez tartozó kérések aláírási sztringjének a Shared Key Lite használatával történő kódolásához használja a következő formátumot:

StringToSign = Date + "\n"
               CanonicalizedResource

Az alábbi példa egy tábla létrehozása művelethez tartozó aláírási sztringet mutat be.

Sun, 11 Oct 2009 19:52:39 GMT\n/testaccount1/Tables

Ezután kódolja ezt a sztringet a HMAC-SHA256 algoritmussal, hozza létre a Authorization fejlécet, majd adja hozzá a fejlécet a kéréshez. Az alábbi példa ugyanahhoz a Authorization művelethez tartozó fejlécet mutatja be:

Authorization: SharedKeyLite testaccount1:uay+rilMVayH/SVI8X+a3fL8k/NxCnIePdyZSkqvydM=

A canonicalizált fejlécek sztringjének létrehozása

Az aláírási sztring CanonicalizedHeaders részének létrehozásához kövesse az alábbi lépéseket:

  1. Kérje le a következővel x-ms-kezdődő erőforrás összes fejlécét, beleértve a x-ms-date fejlécet is.

  2. Alakítsa át az egyes HTTP-fejléceket kisbetűssé.

  3. Rendezze a fejléceket lexikálisan a fejléc neve szerint, növekvő sorrendben. Minden fejléc csak egyszer jelenhet meg a sztringben.

    Megjegyzés

    A lexikográfiai rendezés nem mindig egyezik meg a hagyományos betűrendezéssel.

  4. Cserélje le a fejlécértékben lévő lineáris térközt egyetlen szóközre.

A lineáris térköz magában foglalja a kocsivissza-/sorbetöltést (CRLF), a szóközöket és a füleket. További részletekért lásd: RFC 2616, 4.2. szakasz . Idézőjeles sztringben ne cserélje le a szóközt.

  1. Vágja le a kettőspont körüli térközt a fejlécben.

  2. Végül fűzze hozzá az új sor karaktert az eredményül kapott lista minden egyes canonicalizált fejlécéhez. A sztringet úgy CanonicalizedHeaders hozhatja létre, hogy a lista összes fejlécét egyetlen sztringbe egyesíti.

Az alábbiakban egy példa látható egy canonicalizált fejlécsztringre:

x-ms-date:Sat, 21 Feb 2015 00:48:38 GMT\nx-ms-version:2014-02-14\n

Megjegyzés

A 2016-05-31-es szolgáltatásverzió előtt az üres értékeket tartalmazó fejlécek ki lettek hagyva az aláírási sztringből. Ezek mostantól a CanonicalizedHeadersben jelennek meg úgy, hogy azonnal követik a kettőspont karaktert a végződő new-line karakterrel.

A canonicalizált erőforrás-sztring létrehozása

Az CanonicalizedResource aláírási sztring része a kérés által megcélzott tárolási szolgáltatások erőforrását jelöli. Az erőforrás URI-jából származtatott sztring bármely részét CanonicalizedResource pontosan úgy kell kódolni, mint az URI-ban.

A sztringnek két támogatott formátuma CanonicalizedResource van:

  • A Blob- és Queue-szolgáltatások 2009-09-19-es és újabb verzióihoz, valamint a Fájlszolgáltatás 2014-02-14-es és újabb verziójához használható megosztott kulcs engedélyezését támogató formátum.

  • Olyan formátum, amely támogatja a Megosztott kulcsot és a Megosztott kulcs Lite szolgáltatást a Table szolgáltatás összes verziójához, valamint a Shared Key Lite 2009-09-19-es és újabb verzióit a Blob- és Queue-szolgáltatásokhoz. Ez a formátum megegyezik a tárolási szolgáltatások korábbi verzióival.

Ha segítségre van szüksége az elérni kívánt erőforrás URI-jának összeállításához, tekintse meg az alábbi témakörök egyikét:

Fontos

Ha a tárfiókot olvasási hozzáférésű georeplikációval (RA-GRS) replikálja, és a másodlagos helyen fér hozzá egy erőforráshoz, ne vegye fel a karakterláncba a –secondary megjelölést CanonicalizedResource . A sztring CanonicalizedResource URI-jában használt erőforrás URI-jának az elsődleges helyen lévő erőforrás URI-jának kell lennie.

Megjegyzés

Ha a táremulátoron engedélyezi az engedélyezést, a fióknév kétszer jelenik meg a sztringben CanonicalizedResource . Ez a várható eredmény. Ha az Azure Storage-szolgáltatásokon engedélyezi az engedélyezést, a fióknév csak egyszer jelenik meg a CanonicalizedResource sztringben.

Megosztott kulcs formátuma a 2009.09.19-i és újabb verziókhoz

Ez a formátum támogatja a Megosztott kulcs engedélyezését a Blob- és Queue-szolgáltatások 2009-09-19-es és újabb verzióihoz, valamint a Fájlszolgáltatások 2014-02-14-es és újabb verzióihoz. A sztringet CanonicalizedResource az alábbi formátumban hozhatja létre:

  1. Egy üres sztringgel ("") kezdődően fűzze hozzá a perjelet (/), majd annak a fióknak a nevét, amely az elérni kívánt erőforrás tulajdonosa.

  2. Fűzze hozzá az erőforrás kódolt URI-elérési útját lekérdezési paraméterek nélkül.

  3. Kérje le az erőforrás URI-jának összes lekérdezési paraméterét, beleértve a comp paramétert is, ha létezik.

  4. Alakítsa át az összes paraméternevet kisbetűsre.

  5. A lekérdezési paramétereket lexikálisan, paraméternév szerint, növekvő sorrendben rendezheti.

  6. URL-dekódolja az egyes lekérdezési paraméterek nevét és értékét.

  7. Adjon meg egy új sor karaktert (\n) az egyes név-érték párok elé.

  8. Fűzze hozzá az egyes lekérdezési paraméterek nevét és értékét a sztringhez a következő formátumban, és ügyeljen arra, hogy a kettőspontot (:) a név és az érték között:

    parameter-name:parameter-value

  9. Ha egy lekérdezési paraméter egynél több értékkel rendelkezik, rendezze az összes értéket lexikálisan, majd foglalja bele őket egy vesszővel tagolt listába:

    parameter-name:parameter-value-1,parameter-value-2,parameter-value-n

Tartsa szem előtt a következő szabályokat a canonicalizált erőforrás-sztring felépítéséhez:

  • Ne használja az új sor karaktert (\n) a lekérdezési paraméterek értékeiben. Ha használni kell, győződjön meg arról, hogy nincs hatással a canonicalizált erőforrás-sztring formátumára.

  • Ne használjon vesszőket a lekérdezési paraméterértékekben.

Íme néhány példa, amelyek az CanonicalizedResource aláírási sztring egy részét mutatják be, mivel az egy adott kérelem URI-jából hozható létre:

Get Container Metadata  
   GET http://myaccount.blob.core.windows.net/mycontainer?restype=container&comp=metadata
CanonicalizedResource:  
    /myaccount/mycontainer\ncomp:metadata\nrestype:container  
  
List Blobs operation:  
    GET http://myaccount.blob.core.windows.net/container?restype=container&comp=list&include=snapshots&include=metadata&include=uncommittedblobs  
CanonicalizedResource:  
    /myaccount/mycontainer\ncomp:list\ninclude:metadata,snapshots,uncommittedblobs\nrestype:container  
  
Get Blob operation against a resource in the secondary location:  
   GET https://myaccount-secondary.blob.core.windows.net/mycontainer/myblob  
CanonicalizedResource:  
    /myaccount/mycontainer/myblob

Shared Key Lite és Table service format for 2009-09-19 and later

Ez a formátum támogatja a Megosztott kulcs és a Megosztott kulcs Lite szolgáltatást a Table szolgáltatás összes verziójához, a Shared Key Lite-ot pedig a Blob- és Queue-szolgáltatások 2009-09-19-es és újabb verzióihoz, valamint a Fájlszolgáltatás 2014-02-14-es és újabb verzióit. Ez a formátum megegyezik a tárolási szolgáltatások korábbi verzióival. A sztringet CanonicalizedResource az alábbi formátumban hozhatja létre:

  1. Egy üres sztringgel ("") kezdődően fűzze hozzá a perjelet (/), majd annak a fióknak a nevét, amely az elérni kívánt erőforrás tulajdonosa.

  2. Fűzze hozzá az erőforrás kódolt URI-elérési útját. Ha a kérelem URI-ja az erőforrás egy összetevőjére vonatkozik, fűzze hozzá a megfelelő lekérdezési sztringet. A lekérdezési sztringnek tartalmaznia kell a kérdőjelet és a comp paramétert (például ?comp=metadata). A lekérdezési sztringben nem szerepelhetnek más paraméterek.

Az aláírás kódolása

Az aláírás kódolásához hívja meg a HMAC-SHA256 algoritmust az UTF-8 kódolású aláírási sztringen, és kódolja az eredményt Base64-ként. Vegye figyelembe, hogy a tárfiók kulcsának Base64-dekódolására is szükség van. Használja a következő formátumot (pszeudokódként jelenik meg):

Signature=Base64(HMAC-SHA256(UTF8(StringToSign), Base64.decode(<your_azure_storage_account_shared_key>)))

Lásd még