Engedélyezés megosztott kulccsal

Cikk
05/15/2024

A tárolási szolgáltatással kapcsolatos minden kérést engedélyezni kell, kivéve, ha a kérés egy nyilvános vagy aláírt hozzáféréshez elérhetővé tett blob- vagy tárolóerőforráshoz tartozik. A kérések engedélyezésének egyik lehetősége a jelen cikkben ismertetett megosztott kulcs használata.

Fontos

Az optimális biztonság érdekében a Microsoft a Microsoft Entra ID felügyelt identitásokkal való használatát javasolja a blob-, üzenetsor- és táblaadatokkal kapcsolatos kérések engedélyezéséhez, amikor csak lehetséges. A Microsoft Entra ID és felügyelt identitásokkal történő engedélyezés kiváló biztonságot és egyszerű használatot biztosít a megosztott kulcsok engedélyezéséhez. További információ: Engedélyezés Microsoft Entra ID. A felügyelt identitásokkal kapcsolatos további információkért lásd : Mik azok az Azure-erőforrások felügyelt identitásai.

Az Azure-on kívül üzemeltetett erőforrásokhoz, például a helyszíni alkalmazásokhoz felügyelt identitásokat használhat az Azure Arcon keresztül. Az Azure Arc-kompatibilis kiszolgálókon futó alkalmazások például felügyelt identitásokkal csatlakozhatnak az Azure-szolgáltatásokhoz. További információ: Hitelesítés Azure-erőforrásokon azure Arc-kompatibilis kiszolgálókkal.

Olyan esetekben, amikor közös hozzáférésű jogosultságkódokat (SAS) használnak, a Microsoft egy felhasználói delegálási SAS használatát javasolja. A felhasználói delegálási SAS-t a fiókkulcs helyett Microsoft Entra hitelesítő adatok védik. A közös hozzáférésű jogosultságkódokról a felhasználói delegálási SAS Létrehozás című témakörben olvashat.

A Blob, a Queue, a Table és a File szolgáltatás a következő megosztott kulcs 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óhoz (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, a Queue és a File szolgáltatásokkal kapcsolatban. A megosztott kulcs engedélyezése a 2009-09-19-es és újabb verzióban 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 a kiterjesztett aláírás használatának engedélyezéséhez.
Megosztott kulcs a Table Service-hez. 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óban ugyanazt az aláírási sztringet használja, mint a Table szolgáltatás korábbi verzióiban.
Shared Key Lite. A Shared Key Lite engedélyezési sémával kéréseket intézhet a Blob, a Queue, a Table és a File szolgáltatásokhoz.

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

Az engedélyezett kérelmekhez két fejlécre van szükség: a vagy x-ms-date a Date fejlécre és a fejlécreAuthorization. Az alábbi szakaszok bemutatják, 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ó: Hozzáférés kezelése az Azure Storage-erőforrásokhoz. Egy tároló, blob, üzenetsor vagy tábla elérhetővé tehető aláírt hozzáféréshez közös hozzáférésű jogosultságkódon keresztül; 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érelemnek tartalmaznia kell a kérelemhez tartozó utc.utc időbélyeget. Az időbélyeget a fejlécben vagy a x-ms-date szabványos HTTP/HTTPS Date fejlécben adhatja meg. Ha mindkét fejléc meg van adva a kérelemben, a rendszer a kérelem létrehozási idejeként használja az értékét x-ms-date .

A tárolási szolgáltatások biztosítják, hogy a kérések a szolgáltatás eléréséig legfeljebb 15 perccel legyenek 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 fájlban, 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ési 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>"

ahol SharedKey vagy SharedKeyLite az engedélyezési séma neve, AccountName az erőforrást kérő fiók neve, és Signature egy kivonatalapú üzenethitelesítési kód (HMAC), amely a kérelemből lett létrehozva, és az SHA256 algoritmus használatával lett kiszámítva, majd Base64 kódolással kódolva.

Megjegyzés

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

Az alábbi szakaszok ismertetik a fejléc felépítését Authorization .

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

Az aláírási sztring létrehozásának módjától függ, hogy melyik szolgáltatásra és verzióra van engedélyezve, é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 a GET vagy a PUT, és nagybetűsnek kell lennie.
A blob-, üzenetsor- és fájlszolgáltatások megosztott kulcsának 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).
A szabványos HTTP-fejlécek értékeit az aláírási formátumban megjelenített sorrendben kell szerepeltetni a sztringben a fejlécnevek nélkül. 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ének. Ebben az esetben kövesse a canonicalizált fejlécek sztringjének összeállítása szakaszban található utasításokat a x-ms-date fejléc hozzáadásához.

Elfogadható mind a, Datemind x-ms-date az ; 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écnév nélkül.
Az aláírási sztringben minden megjelenített új sorkarakterek (\n) megadása kötelező.
Az aláírási sztring canonicalizált fejléceket és canonicalizált erőforrás-sztringeket tartalmaz. A sztringek 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 a 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 Tartalomhossz mezőnek üres sztringnek kell lennie, ha a kérelem tartalomhossza nulla. A 2014-02-14-es és korábbi verziókban a tartalom hossza akkor is szerepel, ha nulla. A régi viselkedésről az alábbiakban talál további információt.

Az alábbi példa egy aláírási sztringet mutat be egy Blob lekérése művelethez. 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 sorról sorra lebontva az egyes sztringrészek láthatók:

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 ugyanahhoz a Authorization művelethez tartozó fejlécet 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 kulcs engedélyezését, 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, a meglévő Authorization fejléceket úgy módosíthatja, hogy megosztott kulcs helyett a Shared Key Lite-ot használják. 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óiban 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 olvasási hozzáférésű 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 a StringToSign értékre 0. Ez általában egy üres sztring.

Az alábbi kérés esetében például a Content-Length fejléc értéke akkor is szerepel a StringToSign fejlécben, ha 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 következőhöz egy ü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, a Table szolgáltatással szembeni kérés engedélyezéséhez megosztott kulcsos hitelesítést kell használnia. A Megosztott kulcs aláírási sztringjének formátuma a Table szolgáltatásban ugyanaz, mint az összes verziónál.

A Table szolgáltatáshoz tartozó kérés megosztottkulcs-aláírási sztringje némileg eltér a Blob vagy a Queue szolgáltatással szembeni 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érelem beállítja a fejlécet x-ms-date . Ha a kérelem be van állítódva x-ms-date, a rendszer ezt az értéket használja a Date fejléc értékéhez is.

A REST API-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 Shared Key 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 szerezheti meg 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ás felé 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" +  
               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 ugyanannak a műveletnek a Authorization fejlécét 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éseket.

A Table service-hez tartozó kérés 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 aláírási sztringet mutat be egy Létrehozás Table művelethez.

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érelemhez. Az alábbi példa ugyanannak a műveletnek a Authorization fejlécét mutatja be:

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

A canonicalized headers sztring létrehozása

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

Kérje le az erőforrás összes fejlécét, amely a következővel x-ms-kezdődik: , beleértve a x-ms-date fejlécet is.
Alakítsa át az egyes HTTP-fejlécneveket kisbetűssé.
A fejlécek lexikális rendezése fejlécnév 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.
Cserélje le a fejlécérték bármely lineáris térközét egyetlen szóközre.

A lineáris térköz magában foglalja a kocsivissza/sortöré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 térközt.

Vágja le a kettőspont körüli térközt a fejlécben.
Végül fűzze hozzá az új sor karaktert az eredményül kapott lista minden egyes canonicalizált fejlécéhez. Hozza létre a CanonicalizedHeaders sztringet a lista összes fejlécének egyetlen sztringgé összefűzésével.

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ási verzió előtt az aláírási sztringből üres értékeket tartalmazó fejlécek kimaradtak. Ezek mostantól a CanonicalizedHeadersben jelennek meg, ha közvetlenül a kettőspont karaktert követik az új sor megszakításával.

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ási erőforrást jelöli. Az erőforrás URI-jából származtatott sztring CanonicalizedResource bármely részét pontosan úgy kell kódolni, ahogyan az az URI-ban található.

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

A Blob- és Queue-szolgáltatások 2009-09-19-es és újabb verzióiban, valamint a Fájlszolgáltatás 2014-02-14-es és újabb verzióiban a megosztott kulcs engedélyezését támogató formátum.
Olyan formátum, amely támogatja a Megosztott kulcsot és a Megosztott kulcs Lite-ot a Table szolgáltatás minden verziójához, valamint a Shared Key Lite 2009-09-19-es és újabb verzióihoz a Blob- és Queue-szolgáltatásokban. Ez a formátum megegyezik a tárolási szolgáltatások korábbi verzióiban használt formátummal.

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:

Blob szolgáltatás: Tárolók, blobok és metaadatok elnevezése és hivatkozása
Üzenetsor-szolgáltatás: Üzenetsor-szolgáltatás erőforrásainak kezelése
Table service: A Table Service erőforrásainak kezelése
Fájlszolgáltatás: Megosztások, könyvtárak, fájlok és metaadatok elnevezése és hivatkozása

Fontos

Ha a tárfiókot írásvédett georeplikációval (RA-GRS) replikálja, és a másodlagos helyen fér hozzá egy erőforráshoz, ne foglalja bele a sztringbe a –secondaryCanonicalizedResource megjelölést. Az URI sztringben CanonicalizedResource használt erőforrás URI-jának az elsődleges helyen található 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 sztringben CanonicalizedResource .

Megosztott kulcs formátuma 2009-09-19-hez é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. Hozza létre a sztringet CanonicalizedResource ebben a formátumban az alábbiak szerint:

Egy üres sztringgel ("") kezdve fűzze hozzá a perjelet (/), majd annak a fióknak a nevét, amely az elérni kívánt erőforrás tulajdonosa.
Fűzze hozzá az erőforrás kódolt URI-útvonalát lekérdezési paraméterek nélkül.
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.
Alakítsa át az összes paraméternevet kisbetűssé.
A lekérdezési paramétereket lexikálisan, paraméternév szerint, növekvő sorrendbe rendezheti.
URL-dekódolja az egyes lekérdezési paraméterek nevét és értékét.
Adjon meg egy új sor karaktert (\n) az egyes név-érték párok elé.
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 tartalmazza a kettőspontot (:) a név és az érték között:

parameter-name:parameter-value
Ha egy lekérdezési paraméter több értékkel rendelkezik, rendezze az összes értéket lexikálisan, majd foglalja ő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 összeállításához:

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.
Kerülje a vesszők használatát 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érés 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 minden 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óiban használt formátummal. Hozza létre a sztringet CanonicalizedResource ebben a formátumban az alábbiak szerint:

Egy üres sztringgel ("") kezdve fűzze hozzá a perjelet (/), majd annak a fióknak a nevét, amely az elérni kívánt erőforrás tulajdonosa.
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>)))

Share via

Engedélyezés megosztott kulccsal

A Dátum fejléc megadása

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

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

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

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

Table service (megosztott kulcs engedélyezése)

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

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

A canonicalized headers sztring létrehozása

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

Megosztott kulcs formátuma 2009-09-19-hez és újabb verziókhoz

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

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

Lásd még

További források