Autorizace se sdíleným klíčem

Článek
11/18/2024

Všechny požadavky provedené vůči službě úložiště musí být autorizované, pokud se nejedná o prostředek objektu blob nebo kontejneru, který byl zpřístupněn pro veřejný nebo podepsaný přístup. Jednou z možností pro autorizaci žádosti je použití sdíleného klíče popsaného v tomto článku.

Důležitý

Pro zajištění optimálního zabezpečení microsoft doporučuje Microsoft Entra ID se spravovanými identitami autorizovat požadavky na data objektů blob, fronty a tabulek, kdykoli je to možné. Autorizace s ID Microsoft Entra a spravovanými identitami poskytuje vynikající zabezpečení a snadné použití prostřednictvím autorizace sdíleného klíče. Další informace najdete v tématu Autorizace pomocíMicrosoft Entra ID . Další informace o spravovaných identitách najdete v tématu Co jsou spravované identity pro prostředky Azure.

Pro prostředky hostované mimo Azure, jako jsou místní aplikace, můžete použít spravované identity prostřednictvím služby Azure Arc. Aplikace spuštěné na serverech s podporou Azure Arc můžou například používat spravované identity pro připojení ke službám Azure. Další informace najdete v tématu Ověřování prostředků Azure pomocí serverů s podporou Azure Arc.

Ve scénářích, ve kterých se používají sdílené přístupové podpisy (SAS), microsoft doporučuje používat SAS delegování uživatele. Sas delegování uživatele je zabezpečený pomocí přihlašovacích údajů Microsoft Entra místo klíče účtu. Informace o sdílených přístupových podpisech najdete v tématu Vytvoření SAS delegování uživatele.

Služby Blob, Queue, Table a File podporují následující schémata autorizace sdíleného klíče pro verzi 2009-09-19 a novější (pro službu Blob, Queue a Table Service) a verzi 2014-02-02-14 a novější (pro souborovou službu):

Sdílený klíč pro službu Blob, Queue a File Services. Pomocí schématu autorizace sdíleného klíče můžete provádět požadavky na služby Blob, Queue a File. Autorizace sdíleného klíče ve verzi 2009-09-19 a novější podporuje rozšířený podpisový řetězec pro lepší zabezpečení a vyžaduje, abyste službu aktualizovali tak, aby autorizovala použití tohoto rozšířeného podpisu.
Sdílený klíč pro službu Table Service Pomocí schématu autorizace sdíleného klíče můžete provádět požadavky na službu Table Pomocí rozhraní REST API. Autorizace sdíleného klíče pro službu Table Service ve verzi 2009-09-19 a novější používá stejný řetězec podpisu jako v předchozích verzích služby Table Service.
Sdílený klíč Lite. Pomocí schématu autorizace sdíleného klíče Lite můžete provádět požadavky na služby Blob, Queue, Table a File. Sdílený klíč Lite není podporovaný pro objekty blob stránky úrovně Premium.

Ve verzi 2009-09-19 a novějších službách Blob a Queue podporuje autorizace sdíleného klíče Lite použití řetězce podpisu, který je stejný jako u sdílených klíčů v předchozích verzích služeb Blob a Queue. Sdílený klíč Lite proto můžete použít k provádění požadavků na služby Blob a Queue bez aktualizace řetězce podpisu.

Autorizovaný požadavek vyžaduje dvě hlavičky: hlavičku Date nebo x-ms-date a hlavičku Authorization. Následující části popisují, jak tyto hlavičky vytvořit.

Důležitý

Azure Storage podporuje protokol HTTP i HTTPS, ale důrazně se doporučuje používat HTTPS.

Poznámka

Kontejner nebo objekt blob je možné zpřístupnit pro veřejný přístup nastavením oprávnění kontejneru. Další informace najdete v tématu Správa přístupu k prostředkům služby Azure Storage. Kontejner, objekt blob, fronta nebo tabulka lze zpřístupnit pro podepsaný přístup prostřednictvím sdíleného přístupového podpisu; sdílený přístupový podpis je autorizovaný jiným mechanismem. Další podrobnosti najdete v tématu Delegování přístupu pomocí sdíleného přístupového podpisu.

Zadání záhlaví Data

Všechny autorizované žádosti musí obsahovat časové razítko UTC (Coordinated Universal Time). Časové razítko můžete zadat buď v hlavičce x-ms-date, nebo ve standardní hlavičce HTTP/HTTPS Date. Pokud jsou v požadavku zadány obě hlavičky, použije se hodnota x-ms-date jako čas vytvoření požadavku.

Služby úložiště zajišťují, že požadavek není starší než 15 minut v době, kdy dorazí do služby. To chrání před určitými útoky na zabezpečení, včetně přehrání útoků. Pokud tato kontrola selže, server vrátí kód odpovědi 403 (Zakázáno).

Poznámka

Hlavička x-ms-date je poskytována, protože některé klientské knihovny a proxy servery HTTP automaticky nastavují hlavičku Date a nedávají vývojáři příležitost číst jeho hodnotu, aby ji mohli zahrnout do autorizovaného požadavku. Pokud nastavíte x-ms-date, vytvořte podpis s prázdnou hodnotou hlavičky Date.

Zadání autorizační hlavičky

Autorizovaný požadavek musí obsahovat hlavičku Authorization. Pokud tato hlavička není zahrnutá, požadavek je anonymní a bude úspěšný pouze u kontejneru nebo objektu blob, který je označen pro veřejný přístup, nebo pro kontejner, objekt blob, frontu nebo tabulku, pro kterou byl sdílený přístupový podpis poskytnut pro delegovaný přístup.

Pokud chcete žádost autorizovat, musíte žádost podepsat klíčem pro účet, který žádost vytváří, a předat tento podpis jako součást požadavku.

Formát záhlaví Authorization je následující:

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

kde SharedKey nebo SharedKeyLite je název schématu autorizace, AccountName je název účtu, který žádá o prostředek, a Signature je kód HMAC (Hash-based Message Authentication Code) vytvořený z požadavku a vypočítaný pomocí algoritmu SHA256 a kódovaný pomocí kódování Base64.

Poznámka

Pokud je tento prostředek veřejně přístupný, je možné požádat o prostředek, který se nachází pod jiným účtem.

Následující části popisují, jak vytvořit hlavičku Authorization.

Vytvoření řetězce podpisu

Způsob vytvoření řetězce podpisu závisí na tom, jakou službu a verzi autorizujete a jaké schéma autorizace používáte. Při vytváření řetězce podpisu mějte na paměti následující skutečnosti:

Část řetězce verb je příkaz HTTP, například GET nebo PUT, a musí být velkými písmeny.
Pro autorizaci sdíleného klíče pro služby Blob, Queue a File se každá hlavička obsažená v řetězci podpisu může zobrazit pouze jednou. Pokud je nějaká hlavička duplikovaná, vrátí služba stavový kód 400 (Chybný požadavek).
Hodnoty všech standardních hlaviček HTTP musí být zahrnuty do řetězce v pořadí uvedeném ve formátu podpisu bez názvů hlaviček. Tyto hlavičky mohou být prázdné, pokud nejsou zadány jako součást požadavku; v takovém případě se vyžaduje pouze znak nového řádku.
Pokud je zadaná hlavička x-ms-date, můžete hlavičku Date ignorovat bez ohledu na to, jestli je zadána v požadavku, a jednoduše zadat prázdný řádek pro Date část řetězce podpisu. V tomto případě postupujte podle pokynů v části Vytvoření řetězce kanonických hlaviček pro přidání hlavičky x-ms-date.

Je přijatelné zadat x-ms-date i Date; v tomto případě služba používá hodnotu x-ms-date.
Pokud není zadána hlavička x-ms-date, zadejte do řetězce podpisu záhlaví Date bez zahrnutí názvu záhlaví.
Všechny zobrazené znaky nového řádku (\n) jsou vyžadovány v řetězci podpisu.
Řetězec podpisu obsahuje kanonické hlavičky a kanonické řetězce prostředků. Kanonizace těchto řetězců je umístí do standardního formátu, který služba Azure Storage rozpozná. Podrobné informace o vytváření CanonicalizedHeaders a CanonicalizedResource řetězců, které tvoří součást řetězce podpisu, najdete v příslušných částech dále v tomto tématu.

Blob, Queue a File Services (autorizace sdíleného klíče)

K kódování řetězce podpisu sdíleného klíče pro požadavek na verzi 2009-09-19 a novější služby Blob nebo Queue Service a verze 2014-02-14 a novější souborové služby použijte následující formát:

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;

Důležitý

V aktuální verzi musí být pole Content-Length prázdný řetězec, pokud je délka obsahu požadavku nula. Ve verzi 2014-02-14 a starší byla délka obsahu zahrnuta i v případě, že nula. Další informace o starém chování najdete níže.

Následující příklad ukazuje řetězec podpisu pro operaci Get Blob. Pokud neexistuje žádná hodnota záhlaví, je zadán pouze znak nového řádku.

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

Rozdělením této řádkové řady se zobrazí každá část stejného řetězce:

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

Dále tento řetězec zakódujte pomocí algoritmu HMAC-SHA256 přes řetězec podpisu s kódováním UTF-8, sestavte hlavičku Authorization a přidejte hlavičku do požadavku. Následující příklad ukazuje hlavičku Authorization pro stejnou operaci:

Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=

Pokud chcete používat autorizaci pomocí sdíleného klíče s verzí 2009-09-19 a novějšími službami Blob and Queue, musíte aktualizovat kód tak, aby používal tento rozšířený řetězec podpisu.

Pokud dáváte přednost migraci kódu na verzi 2009-09-19 nebo novější služby Blob a Queue s co nejmenšími možnými změnami, můžete stávající hlavičky Authorization upravit tak, aby místo sdíleného klíče používaly sdílený klíč Lite. Formát podpisu vyžadovaný sdíleným klíčem Lite je shodný s formátem sdílený klíč vyžadovaný verzemi služeb Blob a Queue před 9. 9. 2009.

Důležitý

Pokud přistupujete k sekundárnímu umístění v účtu úložiště, pro který je povolená geografická replikace jen pro čtení (RA-GRS), nezahrnujte do autorizační hlavičky -secondary označení. Pro účely autorizace je název účtu vždy název primárního umístění, a to i pro sekundární přístup.

Hlavička Content-Length ve verzi 2014-02-14 a starší

Pokud používáte verzi 2014-02-14 nebo starší, je-li Content-Length nula, nastavte Content-Length část StringToSign na 0. Normálně by to byl prázdný řetězec.

Například pro následující požadavek je hodnota hlavičky Content-Length zahrnuta do StringToSign i v případě, že je nulová.

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

StringToSign se konstruuje takto:

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

vzhledem k tomu, že ve verzích po roce 2014-02-14 musí StringToSign obsahovat prázdný řetězec pro 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 (autorizace sdíleného klíče)

Autorizaci sdíleného klíče musíte použít k autorizaci požadavku provedeného ve službě Table Service, pokud vaše služba k provedení požadavku používá rozhraní REST API. Formát řetězce podpisu pro sdílený klíč pro službu Table Service je stejný pro všechny verze.

Řetězec podpisu sdíleného klíče pro požadavek na službu Table service se mírně liší od řetězce požadavku na službu Blob nebo Queue, protože neobsahuje CanonicalizedHeaders část řetězce. Hlavička Date v tomto případě navíc není nikdy prázdná, i když požadavek nastaví hlavičku x-ms-date. Pokud požadavek nastaví x-ms-date, použije se tato hodnota také pro hodnotu hlavičky Date.

Pokud chcete kódovat řetězec podpisu pro požadavek na službu Table Service provedenou pomocí rozhraní REST API, použijte následující formát:

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

Poznámka

Počínaje verzí 2009-09-19 služba Table service vyžaduje, aby všechna volání REST obsahovala hlavičky DataServiceVersion a MaxDataServiceVersion. Další informace najdete v tématu Nastavení hlaviček verzí datové služby OData.

Služby Blob, Queue a File (autorizace sdíleného klíče Lite)

Autorizaci sdíleného klíče Lite můžete použít k autorizaci požadavku provedeného ve verzi 2009-09-19 a novějších služeb Blob and Queue a verze 2014-02-14 a novějších souborových služeb. Sdílený klíč Lite není podporovaný pro objekty blob stránky úrovně Premium.

Řetězec podpisu pro sdílený klíč Lite je shodný s řetězcem podpisu vyžadovaným pro autorizaci sdíleného klíče ve verzích služeb Blob a Queue před 2009-09-19. Pokud tedy chcete migrovat kód s nejmenším počtem změn ve verzi 2009-09-19 služeb Blob and Queue, můžete kód upravit tak, aby používal Sdílený klíč Lite, aniž byste změnili samotný řetězec podpisu. Pomocí sdíleného klíče Lite nezískáte vylepšené funkce zabezpečení poskytované pomocí sdíleného klíče s verzí 2009-09-19 a novější.

K zakódování řetězce podpisu pro požadavek ve službě Blob nebo Queue použijte následující formát:

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

Následující příklad ukazuje řetězec podpisu pro operaci Put Blob. Všimněte si, že řádek záhlaví Content-MD5 je prázdný. Hlavičky zobrazené v řetězci jsou páry name-value, které určují vlastní hodnoty metadat pro nový objekt blob.

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

Authorization: SharedKeyLite myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=

Table Service (autorizace sdíleného klíče Lite)

Autorizaci sdíleného klíče Lite můžete použít k autorizaci požadavku provedeného v jakékoli verzi služby Table Service.

Pokud chcete kódovat řetězec podpisu pro požadavek na službu Table Service pomocí sdíleného klíče Lite, použijte následující formát:

StringToSign = Date + "\n"
               CanonicalizedResource

Následující příklad ukazuje řetězec podpisu pro operaci Create Table.

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

Dále kódujte tento řetězec pomocí algoritmu HMAC-SHA256, sestavte hlavičku Authorization a pak do požadavku přidejte hlavičku. Následující příklad ukazuje hlavičku Authorization pro stejnou operaci:

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

Vytvoření řetězce kanonických hlaviček

Chcete-li vytvořit CanonicalizedHeaders část řetězce podpisu, postupujte takto:

Načtěte všechna záhlaví pro prostředek, který začíná x-ms-, včetně hlavičky x-ms-date.
Převeďte každý název hlavičky HTTP na malá písmena.
Seřaďte záhlaví lexicicky podle názvu záhlaví ve vzestupném pořadí. Každé záhlaví se může v řetězci zobrazit jenom jednou.

Poznámka

lexikální řazení nemusí vždy shodovat s konvenčním abecedním pořadím.
Nahraďte všechny lineární prázdné znaky v hodnotě záhlaví jedinou mezerou.

Lineární prázdné znaky zahrnují návratový/spojnicový kanál (CRLF), mezery a tabulátory. Podrobnosti najdete v RFC 2616 v části 4.2. Nenahrazovat žádné prázdné znaky uvnitř uvozovaného řetězce.

Oříznout libovolné prázdné znaky kolem dvojtečky v záhlaví.
Nakonec do každého kanonického záhlaví ve výsledném seznamu přidejte znak nového řádku. Zřetězením všech hlaviček v tomto seznamu do jednoho řetězce vytvořte řetězec CanonicalizedHeaders.

Následující příklad ukazuje příklad kanonického řetězce hlaviček:

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

Poznámka

Před verzí služby 2016-05-31 byly hlavičky s prázdnými hodnotami vynechány z řetězce podpisu. Ty jsou nyní reprezentovány v CanonicalizedHeaders okamžitě za dvojtečku znak s ukončující nový řádek.

Vytvoření kanonického řetězce prostředků

CanonicalizedResource část řetězce podpisu představuje prostředek služby úložiště, na který cílí požadavek. Jakákoli část řetězce CanonicalizedResource odvozené z identifikátoru URI prostředku by měla být kódována přesně tak, jak je v identifikátoru URI.

Pro řetězec CanonicalizedResource existují dva podporované formáty:

Formát, který podporuje autorizaci sdíleného klíče pro služby Blob a Queue verze 2009-09-19 a novější a verze 2014-02-14 a novější služby File.
Formát, který podporuje sdílený klíč a sdílený klíč Lite pro všechny verze služby Table Service a Sdílený klíč Lite pro verzi 2009-09-19 a novější služby Blob a Queue. Tento formát je shodný s předchozími verzemi služeb úložiště.

Nápovědu k vytvoření identifikátoru URI pro prostředek, ke kterému přistupujete, najdete v jednom z následujících témat:

Blob Service: pojmenování a odkazování na kontejnery, objekty blob a metadata
Služba fronty: adresování prostředků služby fronty
Table Service: adresování prostředků služby Table Service
Souborová služba: pojmenování a odkazování na sdílené složky, adresáře, soubory a metadata

Důležitý

Pokud se váš účet úložiště replikuje s geografickou replikací jen pro čtení (RA-GRS) a přistupujete k prostředku v sekundárním umístění, nezahrnujte do řetězce CanonicalizedResource označení –secondary. Identifikátor URI prostředku použitý v identifikátoru URI řetězce CanonicalizedResource by měl být identifikátor URI prostředku v primárním umístění.

Poznámka

Pokud autorizujete autorizaci v emulátoru úložiště, název účtu se v řetězci CanonicalizedResource zobrazí dvakrát. Očekává se to. Pokud autorizujete služby Azure Storage, název účtu se zobrazí jenom jednou v řetězci CanonicalizedResource.

Formát sdíleného klíče pro 19. 9. 2009 a novější

Tento formát podporuje autorizaci sdíleného klíče pro verzi 2009-09-19 a novější služby Blob a Queue a verzi 2014-02-14 a novější souborových služeb. Vytvořte řetězec CanonicalizedResource v tomto formátu následujícím způsobem:

Počínaje prázdným řetězcem (""), připojte lomítko (/) a za ním název účtu, který vlastní prostředek, ke kterému se přistupuje.
Připojte cestu URI kódovaného prostředku bez jakýchkoli parametrů dotazu.
Načtěte všechny parametry dotazu na identifikátor URI prostředku, včetně parametru comp, pokud existuje.
Převeďte všechny názvy parametrů na malá písmena.
Seřaďte parametry dotazu lexicicky podle názvu parametru ve vzestupném pořadí.
Adresa URL dekóduje každý název a hodnotu parametru dotazu.
Před každou dvojici název-hodnota zahrňte znak nového řádku (\n).
Připojte každý název a hodnotu parametru dotazu k řetězci v následujícím formátu a nezapomeňte zahrnout dvojtečku (:) mezi názvem a hodnotou:

parameter-name:parameter-value
Pokud má parametr dotazu více než jednu hodnotu, seřaďte všechny hodnoty lexikograficky, pak je zahrňte do seznamu odděleného čárkami:

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

Mějte na paměti následující pravidla pro vytvoření kanonického řetězce prostředku:

Nepoužívejte znak nového řádku (\n) v hodnotách parametrů dotazu. Pokud se musí použít, ujistěte se, že nemá vliv na formát kanonického řetězce prostředků.
Nepoužívejte čárky v hodnotách parametrů dotazu.

Tady je několik příkladů, které ukazují CanonicalizedResource část řetězce podpisu, protože se dá vytvořit z daného identifikátoru URI požadavku:

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

Formát služby Shared Key Lite a Table Service pro verzi 2009-09-19 a novější

Tento formát podporuje sdílený klíč a sdílený klíč Lite pro všechny verze služby Table Service a Sdílený klíč Lite pro verzi 2009-09-19 a novější služby Blob a Queue a verze 2014-02-14 a novější služby File Service. Tento formát je shodný s předchozími verzemi služeb úložiště. Vytvořte řetězec CanonicalizedResource v tomto formátu následujícím způsobem:

Počínaje prázdným řetězcem (""), připojte lomítko (/) a za ním název účtu, který vlastní prostředek, ke kterému se přistupuje.
Připojte cestu URI kódovaného prostředku. Pokud identifikátor URI požadavku řeší součást prostředku, připojte příslušný řetězec dotazu. Řetězec dotazu by měl obsahovat otazník a parametr comp (například ?comp=metadata). V řetězci dotazu by neměly být zahrnuty žádné další parametry.

Kódování podpisu

Chcete-li kódovat podpis, zavolejte algoritmus HMAC-SHA256 řetězce podpisu kódování UTF-8 a kódujte výsledek jako Base64. Mějte na paměti, že také potřebujete dekódovat klíč účtu úložiště Base64. Použijte následující formát (zobrazený jako pseudokód):

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

Viz také

rozhraní REST API služby Blob Service
rozhraní REST API služby queue
rozhraní REST API služby Table Service
REST Storage Services

Sdílet prostřednictvím

Autorizace se sdíleným klíčem

Zadání záhlaví Data

Zadání autorizační hlavičky

Vytvoření řetězce podpisu

Blob, Queue a File Services (autorizace sdíleného klíče)

Hlavička Content-Length ve verzi 2014-02-14 a starší

Table Service (autorizace sdíleného klíče)

Služby Blob, Queue a File (autorizace sdíleného klíče Lite)

Table Service (autorizace sdíleného klíče Lite)

Vytvoření řetězce kanonických hlaviček

Vytvoření kanonického řetězce prostředků

Formát sdíleného klíče pro 19. 9. 2009 a novější

Formát služby Shared Key Lite a Table Service pro verzi 2009-09-19 a novější

Kódování podpisu

Viz také

Další materiály