Engedélyezés megosztott kulccsal

A tárolási szolgáltatással kapcsolatos minden kérést engedélyezni kell, kivéve, ha a kérés olyan blob- vagy tárolóerőforrást igényel, amelyet nyilvános vagy aláírt hozzáférésre tettek elérhetővé. 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 azt javasolja, hogy a Microsoft Entra ID-t felügyelt identitásokkal használva engedélyezze a blob-, üzenetsor- és táblaadatokra vonatkozó kéréseket, amikor csak lehetséges. A Microsoft Entra-azonosítóval és felügyelt identitásokkal való engedélyezés kiváló biztonságot és egyszerű használatot biztosít a megosztott kulcsok engedélyezésével szemben. További információ: Engedélyezés a Microsoft Entra-azonosítóval. A felügyelt identitásokról további információt Az Azure-erőforrások felügyelt identitásaicímű témakörben talál.

Az Azure-on kívül üzemeltetett erőforrások, például a helyszíni alkalmazások esetében 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 az Azure Arc-kompatibilis kiszolgálókon.

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 a Microsoft Entra hitelesítő adatai védik. A közös hozzáférésű jogosultságkódokkal kapcsolatos további információkért lásd: Felhasználói delegálási SAS-létrehozása.

A Blob, a Queue, a Table és a File services a következő közöskulcs-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ájának használatá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 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 közöskulcs-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.

  • Megosztott kulcs Lite. A Shared Key Lite engedélyezési sémával kéréseket kezdeményezhet a Blob-, Üzenetsor-, Táblázat- és Fájlszolgáltatásokhoz. A Shared Key Lite nem támogatott prémium szintű lapblobok esetén.

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

Az engedélyezett kérelmekhez két fejléc szükséges: a Date vagy x-ms-date fejléc és a Authorization fejléc. 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.

Jegyzet

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. 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 információt Hozzáférés delegálása közös hozzáférésű jogosultságkóddal című témakörben talál.

A Dátum fejléc megadása

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

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

Jegyzet

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 beolvassa az értékét, hogy belefoglalja az engedélyezett kérelembe. Ha x-ms-dateállít be, hozza létre az aláírást a Date fejléc üres értékével.

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

Az engedélyezett kérésnek tartalmaznia kell a Authorization fejlécet. 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 Authorization fejléc formátuma 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, Signature pedig egy kivonatalapú üzenethitelesítési kód (HMAC), amely a kérésből jön létre, és az SHA256 algoritmus használatával van kiszámítva, majd Base64 kódolással kódolva.

Jegyzet

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

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

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á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-ige, például GET vagy PUT, és nagybetűsnek kell lennie.

  • A blob-, üzenetsor- és fájlszolgáltatások megosztott kulcsának engedélyezéséhez 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 kell szerepeltetni a sztringben a fejlécnevek nélkül. Ezek az élőfejek üresek lehetnek, ha nincsenek megadva a kérés részeként; ebben az esetben csak az új sor karaktere szükséges.

  • 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 adjon meg egy üres sort az aláírási sztring Date részére. Ebben az esetben kövesse a A x-ms-date fejléc hozzáadásához a canonicalizált fejlécek sztringjének szakaszában található utasításokat.

    Elfogadható x-ms-date és Date; ebben az esetben a szolgáltatás a x-ms-dateértékét használja.

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

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

  • Az aláírási sztring tartalmazza a canonicalized fejléceket és a canonicalizált erőforrás-sztringeket. Ezeknek a sztringeknek a canonicalizálása az Azure Storage által felismert szabványos formátumba helyezi őket. Az aláírási sztring részét képező CanonicalizedHeaders é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)

A megosztott kulcs aláírási sztringjének 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ódolásához 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 szerepelt, 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 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 az UTF-8 kódolású aláírási sztring HMAC-SHA256 algoritmusával, hozza létre a Authorization fejlécet, és adja hozzá a fejlécet a kéréshez. Az alábbi példa ugyanahhoz a művelethez Authorization 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 a bővített aláírási sztring használatához.

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 a Megosztott kulcs Lite-t használja a Megosztott kulcs helyett. A Shared Key Lite által megkövetelt aláírási formátum megegyezik a 2009.09.19. előtti blob- és üzenetsor-szolgáltatások megosztott kulcshoz szükséges formátumával.

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álás (RA-GRS), ne vegye fel a -secondary megjelölést az 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 StringToSignContent-Length részét 0. Ez általában egy üres sztring lenne.

Az alábbi kérés esetében például a Content-Length fejléc értéke akkor is szerepel a StringToSign, 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 a következőképpen épül fel:

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 utáni verziókban a StringToSign ü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ással kapcsolatos 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 némileg eltér a Blob vagy a Queue szolgáltatásra vonatkozó kérésekétól, mivel nem tartalmazza a sztring CanonicalizedHeaders részét. Ezenkívül a Date fejléc ebben az esetben sem üres, még akkor sem, ha a kérés beállítja a x-ms-date fejlécet. Ha a kérelem x-ms-date, akkor a Date fejléc értéke is ezt az értéket használja.

Az aláírási sztring rest API-val végzett Table szolgáltatásra vonatkozó kérések kódolásához használja a következő formátumot:

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

Jegyzet

A Table szolgáltatás a 2009-09-19-es verziótól kezdve megköveteli, hogy minden REST-hívás tartalmazza a DataServiceVersion és MaxDataServiceVersion fejléceket. További információt Az OData Data Service verziófejléceinek beállítása című témakörben talál.

Blob-, üzenetsor- és fájlszolgáltatások (Megosztott kulcsú Lite-engedélyezés)

A Megosztott kulcs Lite-engedélyezéssel engedélyezheti a Blob- és Üzenetsor-szolgáltatások 2009-09-19-es és újabb verzióival, valamint a Fájlszolgáltatások 2014-02-14-es és újabb verziójával kapcsolatos kéréseket. A Shared Key Lite nem támogatott prémium szintű lapblobok esetén.

A Shared Key Lite aláírási sztringje megegyezik a 2009.09.19. előtti blob- és üzenetsor-szolgáltatások 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ában a legkevesebb módosítással szeretné áttelepíteni a kódot, 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 üzenetsor-szolgáltatással kapcsolatos 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 aláírási sztringet mutat be egy Blob művelethez. 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 az UTF-8 kódolású aláírási sztring HMAC-SHA256 algoritmusával, hozza létre a Authorization fejlécet, és adja hozzá a fejlécet a kéréshez. Az alábbi példa ugyanahhoz a művelethez Authorization 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 aláírási sztringet mutat be egy Tábla létrehozása 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éréshez. Az alábbi példa ugyanahhoz a művelethez Authorization fejlécet 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:

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

  2. Konvertálja az egyes HTTP-fejlécek nevét kisbetűssé.

  3. Rendezze a fejléceket lexikográfiailag fejlécnév szerint növekvő sorrendben. Minden fejléc csak egyszer jelenhet meg a sztringben.

    Jegyzet

    Lexikográfiai rendezési nem mindig egyezik a hagyományos betűrendezéssel.

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

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

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

  2. Végül fűzjön hozzá egy új sorjelet az eredményül kapott lista minden egyes canonicalizált fejlécéhez. A CanonicalizedHeaders sztringet úgy hozhatja létre, hogy a lista összes fejlécét egyetlen sztringbe fűzi össze.

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

Jegyzet

A 2016-05-31-es szolgáltatásverzió előtt a rendszer kihagyta az üres értékeket tartalmazó fejléceket az aláírási sztringből. Ezek most már a CanonicalizedHeadersben jelennek meg, ha a kettőspont karaktert közvetlenül követi az új sor végződésével.

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

Az aláírási sztring CanonicalizedResource 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 CanonicalizedResource sztring bármely részét pontosan úgy kell kódolni, mint az URI-ban.

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

  • A Blob- és üzenetsor-szolgáltatások 2009-09-19-es és újabb verziójához, 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-t a Table szolgáltatás összes verziójához, a Shared Key Lite-ot pedig a Blob- és Üzenetsor-szolgáltatások 2009-09-19-es és újabb verzióihoz. 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ók írásvédett georeplikálással (RA-GRS) van replikálva, és egy másodlagos helyen lévő erőforráshoz fér hozzá, ne vegye fel a –secondary megjelölést a CanonicalizedResource sztringbe. A CanonicalizedResource sztring URI-jában használt erőforrás URI-jának kell lennie az elsődleges helyen található erőforrás URI-jának.

Jegyzet

Ha a táremulátoron engedélyezi az engedélyezést, a fióknév kétszer jelenik meg a CanonicalizedResource sztringben. Ez várható. 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 2009-09-19-19-hez és újabb verziókhoz

Ez a formátum támogatja a megosztott kulcsok engedélyezését a Blob- és üzenetsor-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 CanonicalizedResource sztringet az alábbi formátumban hozhatja létre:

  1. Egy üres sztringgel ("") kezdődően fűzze hozzá az előre perjelet (/), majd annak a fióknak a nevét, amely a hozzáférés alatt álló erőforrást birtokolja.

  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. Konvertálja az összes paraméternevet kisbetűssé.

  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 sorjelet (\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őspont (:) a név és az érték között:

    parameter-name:parameter-value

  9. Ha egy lekérdezési paraméter több értékkel is rendelkezik, rendezze az összes értéket lexikálisan, majd vegye fel ő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 az nem befolyásolja a canonicalizált erőforrás-sztring formátumát.

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

Íme néhány példa, amelyek az aláírási sztring CanonicalizedResource 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 formátum 2009-09-19 és újabb verziókhoz

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 üzenetsor-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 CanonicalizedResource sztringet az alábbi formátumban hozhatja létre:

  1. Egy üres sztringgel ("") kezdődően fűzze hozzá az előre perjelet (/), majd annak a fióknak a nevét, amely a hozzáférés alatt álló erőforrást birtokolja.

  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ét kezeli, 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 Base64-nek is dekódolnia kell a tárfiók kulcsát. 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:

  • Last updated on