Autorizace s využitím sdíleného klíče

Článek
05/15/2024

Každý požadavek 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í autorizace požadavku 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 používat Microsoft Entra ID se spravovanými identitami k autorizaci požadavků na data objektů blob, front a tabulek, kdykoli je to možné. Autorizace s Microsoft Entra ID a spravovanými identitami poskytuje vynikající zabezpečení a snadné použití oproti autorizaci 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. Například aplikace spuštěné na serverech s podporou Azure Arc můžou používat spravované identity pro připojení ke službám Azure. Další informace najdete v tématu Ověřování u prostředků Azure na serverech s podporou Azure Arc.

Ve scénářích, ve kterých se používají sdílené přístupové podpisy (SAS), microsoft doporučuje použít 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 Create 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-14 a novější (pro službu File):

Sdílený klíč pro objekty blob, fronty a souborové služby. Pomocí schématu autorizace sdíleného klíče můžete vytvářet požadavky na služby Blob, Queue a File. Autorizace sdíleného klíče ve verzi 2009-09-19 a novějších podporuje řetězec rozšířeného podpisu kvůli rozšířenému zabezpečení a vyžaduje, abyste aktualizovali službu tak, aby autorizaci používala tento rozšířený podpis.
Sdílený klíč pro službu Table Service. Pomocí schématu autorizace sdíleného klíče můžete vytvářet požadavky na službu Table pomocí rozhraní REST API. Autorizace sdíleného klíče pro službu Table 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í autorizačního schématu Sdílený klíč Lite můžete vytvářet požadavky na služby Blob, Queue, Table a File.

Pro verzi 2009-09-19 a novější služby Blob a Queue podporuje autorizace sdíleného klíče Lite použití řetězce podpisu, který byl stejný jako u sdíleného klíče v předchozích verzích služby Blob a Queue. Proto můžete použít sdílený klíč Lite k vytváření 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 protokoly HTTP i HTTPS, ale důrazně doporučujeme používat protokol 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 autorizován jiným mechanismem. Další podrobnosti najdete v tématu Delegování přístupu pomocí sdíleného přístupového podpisu .

Určení záhlaví Date

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

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

Poznámka

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

Zadání hlavičky autorizace

Autorizovaná žádost 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 které byl pro delegovaný přístup poskytnut sdílený přístupový podpis.

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

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

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

kde SharedKey nebo SharedKeyLite je název autorizačního schématu, AccountName je název účtu žádajícího o prostředek a Signature jedná se o kód HMAC (Hash-based Message Authentication Code) vytvořený z požadavku a vypočítaný pomocí algoritmu SHA256 a následně 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, pro kterou 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í:

Část řetězce VERB je příkaz HTTP, například GET nebo PUT, a musí být velká písmena.
V případě autorizace sdíleného klíče pro služby Blob, Queue a File se každá hlavička zahrnutá v řetězci podpisu může zobrazit jenom jednou. Pokud je nějaká hlavička duplikovaná, služba vrátí stavový kód 400 (Chybný požadavek).
Hodnoty všech standardních hlaviček HTTP musí být zahrnuty v řetězci 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 hlavička x-ms-date zadaná, můžete ji ignorovat Date 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 kanonalizovaných hlaviček pro přidání x-ms-date hlavičky.

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

Objekty blob, fronty a souborové služby (autorizace sdíleného klíče)

Pokud chcete kódovat řetězec podpisu sdíleného klíče pro požadavek pro verzi 2009-09-19 a novější služby Blob nebo Queue a verzi 2014-02-14 a novější služby File, 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 nulová. Ve verzi 2014-02-14 a starších verzích byla délka obsahu zahrnuta i v případě nuly. Další informace o starém chování najdete níže.

Následující příklad ukazuje řetězec podpisu pro operaci Get Blob . Tam, kde není žá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

Když rozdělíte tento řádek po řádku, zobrazí se 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 ji do požadavku. Následující příklad ukazuje hlavičku Authorization stejné operace:

Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=

Pokud chcete používat autorizaci sdíleného klíče ve službě Blob a Queue verze 2009-09-19 a novější, musíte aktualizovat kód tak, aby používal tento řetězec rozšířeného 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ším možnými změnami, můžete upravit stávající Authorization hlavičky 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 vyžadovaným pro sdílený klíč verzemi služeb Blob a Queue před 19. 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 s přístupem pro čtení (RA-GRS), nezahrnujte -secondary toto označení do hlavičky autorizace. 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ší, pokud Content-Length je nula, nastavte Content-Length část na StringToSign0hodnotu . Za normálních okolností by to byl prázdný řetězec.

Například pro následující požadavek je hodnota hlavičky Content-Length zahrnuta v hodnotě i v případě StringToSign , ž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

Objekt StringToSign je vytvořen 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, StringToSign že ve verzích po 2014-02-2014 musí 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)

Pokud vaše služba k vytvoření požadavku používá rozhraní REST API, musíte použít autorizaci sdíleného klíče k autorizaci požadavku vytvořeného vůči službě Table. 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 pro požadavek na službu Blob nebo Queue v tom, že nezahrnuje CanonicalizedHeaders část řetězce. Navíc hlavička Date v tomto případě 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 .

K zakódování řetězce podpisu pro požadavek na službu Table service vytvořeného 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 vyžaduje služba Table Service, aby všechna volání REST obsahovala DataServiceVersion hlavičky a MaxDataServiceVersion . Další informace najdete v tématu Nastavení hlaviček verze datové služby OData .

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

Autorizaci pomocí sdíleného klíče Lite můžete použít k autorizaci žádosti o souborové služby z 2009-09-19 a novější služby Blob a Queue a verze 2014-02-14 a novější.

Řetězec podpisu pro sdílený klíč Lite je stejný jako řetězec podpisu vyžadovaný pro autorizaci sdíleným klíčem ve verzích služby Objektů blob a front před 2009-09-19. Pokud tedy chcete migrovat kód s nejmenším počtem změn na verzi 2009-09-19 služby Blob a Queue, můžete kód upravit tak, aby používal sdílený klíč Lite, aniž byste museli měnit samotný řetězec podpisu. Použitím sdíleného klíče Lite nezískáte rozšíř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 na službu blob nebo fronty 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 název-hodnota, které určují hodnoty vlastních 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 pomocí sdíleného klíče Lite)

Autorizaci pomocí sdíleného klíče Lite můžete použít k autorizaci požadavku na libovolnou 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 tento řetězec zakódujte pomocí algoritmu HMAC-SHA256, sestavte hlavičku Authorization a pak přidejte hlavičku do požadavku. 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čte všechny hlavičky pro prostředek, které začínají x-ms-na , včetně hlavičky x-ms-date .
Převeďte názvy každé hlavičky HTTP na malá písmena.
Seřaďte záhlaví lexiograficky podle názvu záhlaví ve vzestupném pořadí. Každé záhlaví se může v řetězci zobrazit pouze jednou.

Poznámka

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

Lineární prázdné znaky zahrnují návrat na začátek řádku nebo odřádkování (CRLF), mezery a tabulátory. Podrobnosti najdete v dokumentu RFC 2616, oddíl 4.2 . Nenahrazujte žádné prázdné znaky uvnitř řetězce v uvozovátku.

Ořízněte všechny prázdné znaky kolem dvojtečky v záhlaví.
Nakonec ke každému kanoizovanému záhlaví ve výsledném seznamu připojte znak nového řádku. CanonicalizedHeaders Sestavte řetězec zřetězením všech hlaviček v tomto seznamu do jednoho řetězce.

Následuje příklad řetězce kanonických 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 znak dvojtečky s ukončující nový řádek.

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

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

Řetězec má dva podporované formáty CanonicalizedResource :

Formát, který podporuje autorizaci sdíleného klíče pro službu Blob a Queue verze 2009-09-19 a novější a pro službu File z 2014-02-14 a novější.
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 službu Blob a Queue verze 2009-09-19 a novější. Tento formát je stejný jako v předchozích verzích služeb úložiště.

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

Blob service: Pojmenování kontejnerů, objektů blob a metadat a odkazování na nich
Queue Service: Adresování prostředků služby front
Služba Table Service: Adresování prostředků služby Table Service
Souborová služba: Pojmenování sdílených složek, adresářů, souborů a metadat a odkazování na je

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 –secondary do CanonicalizedResource řetězce označení . Identifikátor URI prostředku použitý v řetězcovém CanonicalizedResource identifikátoru URI by měl být identifikátorem URI prostředku v primárním umístění.

Poznámka

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

Formát sdíleného klíče pro verzi 2009-09-19 a novější

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

Počínaje prázdným řetězcem (""), připojte lomítko (/) následované názvem účtu, který vlastní prostředek, ke kterému se přistupuje.
Připojte cestu URI s kódováním prostředku bez parametrů dotazu.
Načtěte všechny parametry dotazu pro 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 lexicograficky podle názvu parametru ve vzestupném pořadí.
Adresa URL dekóduje název a hodnotu každého parametru dotazu.
Před každou dvojici název-hodnota zadejte znak nového řádku (\n).
Každý název a hodnotu parametru dotazu připojte 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 lexiograficky a pak je zahrňte do seznamu odděleného čárkami:

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

Pro vytvoření kanonického řetězce prostředků mějte na paměti následující pravidla:

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

Tady je několik příkladů, které znázorňují 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 službu File verze 2009-09-19 a novější služby Blob a Queue a verzi 2014-02-14 a novější. Tento formát je stejný jako v předchozích verzích služeb úložiště. CanonicalizedResource Sestavte řetězec v tomto formátu následujícím způsobem:

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

Kódování podpisu

Pokud chcete podpis zakódovat, zavolejte algoritmus HMAC-SHA256 na řetězec podpisu s kódováním UTF-8 a zakódujte výsledek jako Base64. Mějte na paměti, že je také potřeba klíč účtu úložiště dekódovat pomocí 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>)))

Sdílet prostřednictvím

Autorizace s využitím sdíleného klíče

Určení záhlaví Date

Zadání hlavičky autorizace

Vytvoření řetězce podpisu

Objekty blob, fronty a souborové služby (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 pomocí 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 verzi 2009-09-19 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