Autoryzowanie za pomocą klucza współużytkowanego

Każde żądanie skierowane do usługi magazynu musi być autoryzowane, chyba że żądanie dotyczy zasobu obiektu blob lub kontenera, który został udostępniony dla dostępu publicznego lub podpisanego. Jedną z opcji autoryzowania żądania jest użycie klucza wspólnego opisanego w tym artykule.

Ważny

Aby uzyskać optymalne zabezpieczenia, firma Microsoft zaleca używanie identyfikatora Entra firmy Microsoft z tożsamościami zarządzanymi w celu autoryzowania żądań względem danych obiektów blob, kolejek i tabel, jeśli to możliwe. Autoryzacja przy użyciu identyfikatora Entra firmy Microsoft i tożsamości zarządzanych zapewnia doskonałe zabezpieczenia i łatwość użycia w przypadku autoryzacji klucza współdzielonego. Aby dowiedzieć się więcej, zobacz Authorize with Microsoft Entra ID (Autoryzowanie za pomocą identyfikatora Entra ID firmy Microsoft). Aby dowiedzieć się więcej o tożsamościach zarządzanych, zobacz Co to są tożsamości zarządzane dla zasobów platformy Azure.

W przypadku zasobów hostowanych poza platformą Azure, takich jak aplikacje lokalne, można używać tożsamości zarządzanych za pośrednictwem usługi Azure Arc. Na przykład aplikacje uruchomione na serwerach z obsługą usługi Azure Arc mogą używać tożsamości zarządzanych do łączenia się z usługami platformy Azure. Aby dowiedzieć się więcej, zobacz Uwierzytelnianie w odniesieniu do zasobów platformy Azure przy użyciu serwerów z obsługą usługi Azure Arc.

W przypadku scenariuszy, w których są używane sygnatury dostępu współdzielonego (SAS), firma Microsoft zaleca używanie sygnatury dostępu współdzielonego delegowania użytkowników. Sygnatura dostępu współdzielonego delegowania użytkownika jest zabezpieczona przy użyciu poświadczeń usługi Microsoft Entra zamiast klucza konta. Aby dowiedzieć się więcej o sygnaturach dostępu współdzielonego, zobacz Tworzenie sygnatur dostępu współdzielonego delegowania użytkownika.

Usługi obiektów blob, kolejek, tabel i plików obsługują następujące schematy autoryzacji klucza współużytkowanego dla wersji 2009-09-19 i nowszych (dla usług blob, queue i table) oraz w wersji 2014-02-14 i nowszej (dla usługi plików):

• Klucz współużytkowany dla obiektów blob, kolejek i usług plików. Użyj schematu autoryzacji klucza współużytkowanego, aby wysyłać żądania do usług obiektów blob, kolejek i plików. Autoryzacja klucza współużytkowanego w wersji 2009-09-19 lub nowszej obsługuje rozszerzony ciąg podpisu w celu zapewnienia zwiększonych zabezpieczeń i wymaga zaktualizowania usługi do autoryzowania przy użyciu tego rozszerzonego podpisu.

• Klucz wspólny dla usługi Table Service. Użyj schematu autoryzacji klucza współdzielonego, aby wysyłać żądania do usługi Table Service przy użyciu interfejsu API REST. Autoryzacja klucza wspólnego dla usługi Table Service w wersji 2009-09-19 lub nowszej używa tego samego ciągu podpisu, co w poprzednich wersjach usługi Table Service.

• Klucz wspólny Lite. Użyj schematu autoryzacji Klucz wspólny Lite, aby wysyłać żądania do usług Blob, Queue, Table i File. Funkcja Shared Key Lite nie jest obsługiwana w przypadku stronicowych obiektów blob w warstwie Premium.

  W przypadku wersji 2009-09-19 i nowszych usług obiektów blob i kolejek autoryzacja shared key Lite obsługuje używanie ciągu podpisu identycznego z obsługiwanymi kluczami udostępnionymi w poprzednich wersjach usług Blob i Queue. W związku z tym możesz użyć klucza współdzielonego Lite, aby wysyłać żądania do usług obiektów blob i kolejek bez aktualizowania ciągu podpisu.

Autoryzowane żądanie wymaga dwóch nagłówków: nagłówka Date lub x-ms-date oraz nagłówka Authorization. W poniższych sekcjach opisano sposób konstruowania tych nagłówków.

Ważny

Usługa Azure Storage obsługuje protokół HTTP i HTTPS, ale korzystanie z protokołu HTTPS jest zdecydowanie zalecane.

Nuta

Kontener lub obiekt blob można udostępnić na potrzeby dostępu publicznego, ustawiając uprawnienia kontenera. Aby uzyskać więcej informacji, zobacz Zarządzanie dostępem do zasobów usługi Azure Storage. Kontener, obiekt blob, kolejka lub tabela mogą być udostępniane do uzyskania podpisanego dostępu za pośrednictwem sygnatury dostępu współdzielonego; sygnatura dostępu współdzielonego jest autoryzowana za pomocą innego mechanizmu. Aby uzyskać więcej informacji, zobacz Delegowanie dostępu za pomocą sygnatury dostępu współdzielonego.

Określanie nagłówka Date

Wszystkie autoryzowane żądania muszą zawierać znacznik czasu uniwersalnego koordynowanego (UTC) dla żądania. Znacznik czasu można określić w nagłówku x-ms-date lub w standardowym nagłówku Date HTTP/HTTPS. Jeśli oba nagłówki są określone w żądaniu, wartość x-ms-date jest używana jako czas utworzenia żądania.

Usługi magazynu zapewniają, że żądanie nie jest starsze niż 15 minut po upływie czasu dotarcia do usługi. Chroni to przed niektórymi atakami zabezpieczeń, w tym atakami powtarzania. W przypadku niepowodzenia tego sprawdzania serwer zwraca kod odpowiedzi 403 (Zabronione).

Nuta

Nagłówek x-ms-date jest udostępniany, ponieważ niektóre biblioteki klienta HTTP i serwery proxy automatycznie ustawiają nagłówek Date i nie dają deweloperowi możliwości odczytania jego wartości w celu uwzględnienia go w autoryzowanym żądaniu. Jeśli ustawisz x-ms-date, skonstruuj podpis z pustą wartością nagłówka Date.

Określanie nagłówka autoryzacji

Autoryzowane żądanie musi zawierać nagłówek Authorization. Jeśli ten nagłówek nie jest dołączony, żądanie jest anonimowe i kończy się powodzeniem tylko względem kontenera lub obiektu blob oznaczonego do dostępu publicznego lub kontenera, obiektu blob, kolejki lub tabeli, dla której udostępniono sygnaturę dostępu delegowanego.

Aby autoryzować żądanie, musisz podpisać żądanie przy użyciu klucza dla konta wysyłającego żądanie i przekazać ten podpis w ramach żądania.

Format nagłówka Authorization jest następujący:

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

gdzie SharedKey lub SharedKeyLite jest nazwą schematu autoryzacji, AccountName jest nazwą konta żądającego zasobu, a Signature jest opartym na skrótach kodem uwierzytelniania komunikatów (HMAC) skonstruowanym z żądania i obliczonym przy użyciu algorytmu SHA256, a następnie zakodowanego przy użyciu kodowania Base64.

Nuta

Istnieje możliwość zażądania zasobu znajdującego się pod innym kontem, jeśli ten zasób jest publicznie dostępny.

W poniższych sekcjach opisano sposób konstruowania nagłówka Authorization.

Konstruowanie ciągu podpisu

Sposób konstruowania ciągu podpisu zależy od usługi i wersji, względem której autoryzujesz, oraz od używanego schematu autoryzacji. Podczas konstruowania ciągu podpisu należy pamiętać o następujących kwestiach:

• Część VERB ciągu to czasownik HTTP, taki jak GET lub PUT, i musi być wielkimi literami.

• W przypadku autoryzacji klucza współużytkowanego dla usług Blob, Queue i File każdy nagłówek zawarty w ciągu podpisu może być wyświetlany tylko raz. Jeśli jakikolwiek nagłówek jest zduplikowany, usługa zwraca kod stanu 400 (nieprawidłowe żądanie).

• Wartości wszystkich standardowych nagłówków HTTP muszą być uwzględnione w ciągu w kolejności wyświetlanej w formacie podpisu bez nazw nagłówków. Te nagłówki mogą być puste, jeśli nie są określone w ramach żądania; w takim przypadku wymagany jest tylko znak nowego wiersza.

• Jeśli określono nagłówek x-ms-date, można zignorować nagłówek Date, niezależnie od tego, czy został określony w żądaniu, i po prostu określić pusty wiersz dla części Date ciągu podpisu. W tym przypadku postępuj zgodnie z instrukcjami w Konstruowanie ciągu nagłówków kanonicznych sekcji, aby dodać nagłówek x-ms-date.

  Dopuszczalne jest określenie zarówno x-ms-date, jak i Date; w tym przypadku usługa używa wartości x-ms-date.

• Jeśli nie określono nagłówka x-ms-date, określ nagłówek Date w ciągu podpisu bez uwzględniania nazwy nagłówka.

• Wszystkie znaki nowego wiersza (\n) są wymagane w ciągu podpisu.

• Ciąg podpisu zawiera kanoniczne nagłówki i kanoniczne ciągi zasobów. Canonicalizing tych ciągów umieszcza je w standardowym formacie rozpoznawanym przez usługę Azure Storage. Aby uzyskać szczegółowe informacje na temat konstruowania ciągów CanonicalizedHeaders i CanonicalizedResource tworzących część ciągu podpisu, zobacz odpowiednie sekcje w dalszej części tego tematu.

Usługi obiektów blob, kolejek i plików (autoryzacja klucza współdzielonego)

Aby zakodować ciąg sygnatury klucza współdzielonego dla żądania względem wersji 2009-09-19 i nowszej usługi Blob lub Queue Service oraz w wersji 2014-02-14 i nowszej usługi Plików, użyj następującego formatu:

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;  

Ważny

W bieżącej wersji pole Content-Length musi być pustym ciągiem, jeśli długość zawartości żądania wynosi zero. W wersji 2014-02-14 i starszej długość zawartości została uwzględniona nawet wtedy, gdy zero. Zobacz poniżej, aby uzyskać więcej informacji na temat starego zachowania.

W poniższym przykładzie pokazano ciąg podpisu dla operacji get blob . Jeśli nie ma wartości nagłówka, zostanie określony tylko znak nowego wiersza.

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  

Podział tego wiersza po wierszu w dół pokazuje każdą część tego samego ciągu:

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

Następnie zakoduj ten ciąg przy użyciu algorytmu HMAC-SHA256 za pośrednictwem ciągu podpisu zakodowanego w formacie UTF-8, skonstruuj nagłówek Authorization i dodaj nagłówek do żądania. W poniższym przykładzie przedstawiono nagłówek Authorization dla tej samej operacji:

Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=  

Aby użyć autoryzacji klucza współużytkowanego z wersją 2009-09-19 i nowszymi usługami obiektów blob i kolejek, należy zaktualizować kod, aby używał tego rozszerzonego ciągu podpisu.

Jeśli wolisz przeprowadzić migrację kodu do wersji 2009-09-19 lub nowszej usług obiektów blob i kolejek z najmniejszymi możliwymi zmianami, możesz zmodyfikować istniejące nagłówki Authorization, aby użyć klucza wspólnego Lite zamiast klucza współużytkowanego. Format podpisu wymagany przez klucz wspólny Lite jest identyczny z tym, który jest wymagany dla klucza współużytkowanego przez wersje usług obiektów blob i kolejek przed 2009-09-19.

Ważny

Jeśli uzyskujesz dostęp do lokalizacji pomocniczej na koncie magazynu, dla którego włączono replikację geograficzną dostępu do odczytu (RA-GRS), nie dołączaj oznaczenia -secondary w nagłówku autoryzacji. W celach autoryzacji nazwa konta jest zawsze nazwą lokalizacji podstawowej, nawet w przypadku dostępu pomocniczego.

Nagłówek Content-Length w wersji 2014-02-14 i starszych

W przypadku korzystania z wersji 2014-02-14 lub starszej, jeśli Content-Length ma wartość zero, ustaw Content-Length część StringToSign na wartość 0. Zwykle jest to pusty ciąg.

Na przykład w przypadku następującego żądania wartość nagłówka Content-Length jest uwzględniona w StringToSign nawet wtedy, gdy jest równa zero.

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 jest skonstruowany w następujący sposób:

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

Podczas gdy w wersjach po 2014-02-14 StringToSign musi zawierać pusty ciąg dla 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

Usługa Table Service (autoryzacja klucza współdzielonego)

Należy użyć autoryzacji klucza współdzielonego, aby autoryzować żądanie skierowane do usługi Table Service, jeśli usługa używa interfejsu API REST do wykonania żądania. Format ciągu podpisu dla klucza wspólnego dla usługi Table Service jest taki sam dla wszystkich wersji.

Ciąg sygnatury klucza współdzielonego dla żądania względem usługi Table Service różni się nieco od tego dla żądania względem usługi Blob lub Queue Service, ponieważ nie zawiera on CanonicalizedHeaders części ciągu. Ponadto nagłówek Date w tym przypadku nigdy nie jest pusty, nawet jeśli żądanie ustawia nagłówek x-ms-date. Jeśli żądanie ustawia x-ms-date, ta wartość jest również używana dla wartości nagłówka Date.

Aby zakodować ciąg podpisu dla żądania względem usługi Table Service wykonanej przy użyciu interfejsu API REST, użyj następującego formatu:

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

Nuta

Począwszy od wersji 2009-09-19, usługa Table Service wymaga, aby wszystkie wywołania REST zawierały nagłówki DataServiceVersion i MaxDataServiceVersion. Aby uzyskać więcej informacji, zobacz Ustawianie nagłówków wersji usługi danych OData.

Usługi obiektów blob, kolejek i plików (autoryzacja klucza współdzielonego Lite)

Możesz użyć autoryzacji klucza wspólnego Lite, aby autoryzować żądanie skierowane do wersji 2009-09-19 i nowszej usług obiektów blob i kolejek oraz w wersji 2014-02-14 i nowszych usług plików. Funkcja Shared Key Lite nie jest obsługiwana w przypadku stronicowych obiektów blob w warstwie Premium.

Ciąg podpisu dla klucza wspólnego Lite jest identyczny z ciągiem podpisu wymaganym do autoryzacji klucza współdzielonego w wersjach usług obiektów blob i kolejek przed 2009-09-19. Jeśli więc chcesz przeprowadzić migrację kodu z najmniejszą liczbą zmian do wersji 2009-09-19 usług obiektów blob i kolejek, możesz zmodyfikować kod tak, aby używał klucza współużytkowanego Lite bez zmiany samego ciągu podpisu. Korzystając z wersji 2009-09-19 i nowszych, nie uzyskasz rozszerzonych funkcji zabezpieczeń udostępnianych przy użyciu klucza współużytkowanego w wersji 2009-09-19.

Aby zakodować ciąg podpisu dla żądania względem usługi Blob lub Queue, użyj następującego formatu:

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

W poniższym przykładzie przedstawiono ciąg podpisu dla operacji put blob . Pamiętaj, że wiersz nagłówka Content-MD5 jest pusty. Nagłówki wyświetlane w ciągu to pary name-value, które określają niestandardowe wartości metadanych dla nowego obiektu 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  

Następnie zakoduj ten ciąg przy użyciu algorytmu HMAC-SHA256 za pośrednictwem ciągu podpisu zakodowanego w formacie UTF-8, skonstruuj nagłówek Authorization i dodaj nagłówek do żądania. W poniższym przykładzie przedstawiono nagłówek Authorization dla tej samej operacji:

Authorization: SharedKeyLite myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=  

Table Service (autoryzacja klucza wspólnego Lite)

Możesz użyć autoryzacji klucza współużytkowanego Lite, aby autoryzować żądanie względem dowolnej wersji usługi Table Service.

Aby zakodować ciąg podpisu dla żądania względem usługi Table Service przy użyciu klucza wspólnego Lite, użyj następującego formatu:

StringToSign = Date + "\n"
               CanonicalizedResource  

W poniższym przykładzie pokazano ciąg podpisu dla operacji tworzenia tabeli .

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

Następnie zakoduj ten ciąg przy użyciu algorytmu HMAC-SHA256, skonstruuj nagłówek Authorization, a następnie dodaj nagłówek do żądania. W poniższym przykładzie przedstawiono nagłówek Authorization dla tej samej operacji:

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

Konstruowanie ciągu nagłówków kanonicznych

Aby skonstruować część CanonicalizedHeaders ciągu podpisu, wykonaj następujące kroki:

1. Pobierz wszystkie nagłówki zasobu rozpoczynającego się od x-ms-, w tym nagłówek x-ms-date.

2. Przekonwertuj każdą nazwę nagłówka HTTP na małe litery.

3. Sortuj nagłówki leksykograficznie według nazwy nagłówka w kolejności rosnącej. Każdy nagłówek może być wyświetlany tylko raz w ciągu.

   Nuta

   porządkowanie leksykograficzne może nie zawsze pokrywać się z konwencjonalnym porządkowanie alfabetycznym.

4. Zastąp wszelkie liniowe odstępy w wartości nagłówka pojedynczą spacją.

Białe znaki liniowe obejmują karetki powrotne/liniowe (CRLF), spacje i karty. Aby uzyskać szczegółowe informacje, zobacz RFC 2616, sekcja 4.2. Nie zamieniaj żadnych białych znaków wewnątrz cytowanego ciągu.

1. Przycina wszelkie odstępy wokół dwukropka w nagłówku.

2. Na koniec dołącz znak nowego wiersza do każdego nagłówka kanonicznego na wyświetlonej liście. Skonstruuj ciąg CanonicalizedHeaders, łącząc wszystkie nagłówki na tej liście w jeden ciąg.

Poniżej przedstawiono przykład ciągu nagłówków kanonicznych:

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

Nuta

Przed usługą w wersji 2016-05-31 nagłówki z pustymi wartościami zostały pominięte w ciągu podpisu. Są one teraz reprezentowane w canonicalizedHeaders bezpośrednio po znaku dwukropka z kończeniem nowego wiersza.

Konstruowanie kanonicznego ciągu zasobu

Część CanonicalizedResource ciągu podpisu reprezentuje zasób usług magazynu przeznaczony dla żądania. Każda część ciągu CanonicalizedResource pochodząca z identyfikatora URI zasobu powinna być zakodowana dokładnie tak, jak w identyfikatorze URI.

Istnieją dwa obsługiwane formaty ciągu CanonicalizedResource:

• Format obsługujący autoryzację klucza wspólnego dla wersji 2009-09-19 i nowszych usług obiektów blob i kolejek oraz w wersji 2014-02-14 i nowszej usługi plików.

• Format obsługujący klucz współużytkowany i klucz wspólny Lite dla wszystkich wersji usługi Table i Shared Key Lite w wersji 2009-09-19 i nowszych usług obiektów blob i kolejek. Ten format jest identyczny z formatem używanym w poprzednich wersjach usług magazynu.

Aby uzyskać pomoc przy konstruowaniu identyfikatora URI dla zasobu, do którego uzyskujesz dostęp, zobacz jeden z następujących tematów:

• Blob Service: nazewnictwo i odwoływanie się do kontenerów, obiektów blob i metadanych

• Usługa kolejkowania: adresowanie zasobów usługi kolejki

• Usługa Table Service: adresowanie zasobów usługi Table Service

• Usługa plików: nazewnictwo i odwoływanie się do udziałów, katalogów, plików i metadanych

Ważny

Jeśli konto magazynu jest replikowane przy użyciu replikacji geograficznej dostępu do odczytu (RA-GRS), a uzyskujesz dostęp do zasobu w lokalizacji pomocniczej, nie dołączaj oznaczenia –secondary w ciągu CanonicalizedResource. Identyfikator URI zasobu używany w identyfikatorze URI ciągu CanonicalizedResource powinien być identyfikatorem URI zasobu w lokalizacji podstawowej.

Nuta

Jeśli autoryzujesz emulator magazynu, nazwa konta będzie wyświetlana dwa razy w ciągu CanonicalizedResource. Jest to oczekiwane. Jeśli autoryzujesz usługi Azure Storage, nazwa konta będzie wyświetlana tylko raz w ciągu CanonicalizedResource.

Format klucza wspólnego dla wersji 2009-09-19 lub nowszej

Ten format obsługuje autoryzację klucza wspólnego dla wersji 2009-09-19 i nowszych usług obiektów blob i kolejek oraz 2014-02-14 i nowszych usług plików. Skonstruuj ciąg CanonicalizedResource w tym formacie w następujący sposób:

1. Począwszy od pustego ciągu (""), dołącz ukośnik (/), a następnie nazwę konta, które jest właścicielem zasobu, do którego uzyskuje się dostęp.

2. Dołącz zakodowaną ścieżkę identyfikatora URI zasobu bez żadnych parametrów zapytania.

3. Pobierz wszystkie parametry zapytania dla identyfikatora URI zasobu, w tym parametr comp, jeśli istnieje.

4. Przekonwertuj wszystkie nazwy parametrów na małe litery.

5. Sortuj parametry zapytania leksykograficznie według nazwy parametru w kolejności rosnącej.

6. Dekoduj adres URL każdej nazwy i wartości parametru zapytania.

7. Dołącz znak nowego wiersza (\n) przed każdą parą nazwa-wartość.

8. Dołącz każdą nazwę parametru zapytania i wartość do ciągu w następującym formacie, upewniając się, że zawiera dwukropek (:) między nazwą a wartością:

   parameter-name:parameter-value

9. Jeśli parametr zapytania ma więcej niż jedną wartość, posortuj wszystkie wartości leksykograficznie, a następnie uwzględnij je na liście rozdzielanej przecinkami:

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

Pamiętaj o następujących regułach tworzenia kanonicznego ciągu zasobu:

• Unikaj używania znaku nowego wiersza (\n) w wartościach parametrów zapytania. Jeśli należy go użyć, upewnij się, że nie ma wpływu na format kanonicznego ciągu zasobu.

• Unikaj używania przecinków w wartościach parametrów zapytania.

Poniżej przedstawiono kilka przykładów pokazujących część CanonicalizedResource ciągu podpisu, ponieważ można ją utworzyć na podstawie danego identyfikatora URI żądania:

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

Format usługi Shared Key Lite i Table Service dla wersji 2009-09-19 lub nowszej

Ten format obsługuje klucz współużytkowany i klucz wspólny Lite dla wszystkich wersji usługi Table Oraz klucz udostępniony Lite w wersji 2009-09-19 i nowszych usług obiektów blob i kolejek oraz w wersji 2014-02-14 i nowszej usługi plików. Ten format jest identyczny z formatem używanym w poprzednich wersjach usług magazynu. Skonstruuj ciąg CanonicalizedResource w tym formacie w następujący sposób:

1. Począwszy od pustego ciągu (""), dołącz ukośnik (/), a następnie nazwę konta, które jest właścicielem zasobu, do którego uzyskuje się dostęp.

2. Dołącz zakodowaną ścieżkę identyfikatora URI zasobu. Jeśli identyfikator URI żądania adresuje składnik zasobu, dołącz odpowiedni ciąg zapytania. Ciąg zapytania powinien zawierać znak zapytania i parametr comp (na przykład ?comp=metadata). W ciągu zapytania nie powinny być uwzględniane żadne inne parametry.

Kodowanie podpisu

Aby zakodować podpis, wywołaj algorytm HMAC-SHA256 w ciągu podpisu zakodowanym w formacie UTF-8 i zakoduj wynik jako Base64. Należy również pamiętać, że musisz zdekodować klucz konta magazynu base64. Użyj następującego formatu (pokazanego jako pseudokod):

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

Zobacz też

• interfejs API REST usługi Blob Service
• interfejs API REST usługi kolejkowania
• interfejs API REST usługi Table Service
• Storage Services REST