Autoryzacja przy użyciu klucza wspólnego

Każde żądanie wykonane względem 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ółdzielonego opisanego w tym artykule.

Porada

Usługa Azure Storage obsługuje integrację z Azure Active Directory w celu precyzyjnej kontroli nad dostępem do zasobów magazynu. Azure AD integracja jest obsługiwana dla usług obiektów blob i kolejek. Ponieważ Azure AD zapewnia zarządzanie tożsamościami, możesz autoryzować dostęp do zasobów magazynu bez przechowywania kluczy dostępu do konta w aplikacjach, tak jak w przypadku klucza współdzielonego. Aby uzyskać więcej informacji, zobacz Autoryzowanie za pomocą Azure Active Directory.

Usługi blob, Queue, Table i File obsługują następujące schematy autoryzacji klucza współdzielonego dla wersji 2009-09-19 i nowszych (dla obiektów blob, kolejek i tabel) oraz wersji 2014-02-14 i nowszych (dla usługi plików):

  • Klucz udostępniony dla obiektów blob, kolejek i usług plików. Użyj schematu autoryzacji klucza współdzielonego, aby wysyłać żądania względem usług obiektów blob, kolejek i plików. Autoryzacja klucza współdzielonego w wersji 2009-09-19 lub nowszej obsługuje rozszerzony ciąg podpisu na potrzeby 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 względem usługi Table Service przy użyciu interfejsu API REST. Autoryzacja klucza współdzielonego 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 Shared Key Lite, aby wysyłać żądania względem usług Blob, Queue, Table i File.

    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 tym, co było obsługiwane względem klucza współdzielonego w poprzednich wersjach usług obiektów blob i kolejek. W związku z tym możesz użyć klucza współdzielonego Lite, aby wysyłać żądania względem 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 i nagłówka Authorization . W poniższych sekcjach opisano sposób konstruowania tych nagłówków.

Ważne

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

Uwaga

Kontener lub obiekt blob można udostępnić dla 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ć dostępne do uzyskania podpisanego dostępu za pośrednictwem sygnatury dostępu współdzielonego; sygnatura dostępu współdzielonego jest autoryzowana za pośrednictwem 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 czasu koordynowanego (UTC) dla żądania. Znacznik czasu można określić w nagłówku lub w standardowym nagłówku x-ms-date HTTP/HTTPS Date . 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 od momentu dotarcia do usługi. Chroni to przed pewnymi atakami bezpieczeństwa, w tym atakami powtarzania. Gdy to sprawdzenie zakończy się niepowodzeniem, serwer zwróci kod odpowiedzi 403 (Zabronione).

Uwaga

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

Określanie nagłówka autoryzacji

Autoryzowane żądanie musi zawierać Authorization nagłówek. Jeśli ten nagłówek nie jest uwzględniony, żądanie jest anonimowe i może zakończyć się powodzeniem tylko w przypadku kontenera lub obiektu blob oznaczonego do dostępu publicznego lub kontenera, obiektu blob, kolejki lub tabeli, dla której udostępniono sygnaturę dostępu współdzielonego na potrzeby 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 i Signature jest hash-based Message Authentication Code (HMAC) skonstruowany z żądania i obliczony przy użyciu algorytmu SHA256, a następnie zakodowany przy użyciu kodowania Base64.

Uwaga

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 i którego schematu autoryzacji używasz. Podczas tworzenia 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 mieć wielkie litery.

  • W przypadku autoryzacji klucza współdzielonego dla usług obiektów blob, kolejki i plików każdy nagłówek zawarty w ciągu podpisu może pojawić się 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. Nagłówki te mogą być puste, jeśli nie są określone w ramach żądania; w takim przypadku wymagany jest tylko znak nowego wiersza.

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

    Dopuszczalne jest określenie wartości i x-ms-dateDate; w tym przypadku usługa używa wartości x-ms-date.

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

  • Wszystkie wyświetlane 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 CanonicalizedHeaders ciągów 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 w wersji 2009-09-19 i nowszej usługi Blob lub Queue 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żne

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 przedstawiono 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 ciągu w dół wiersz po wierszu 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 Authorization nagłówek i dodaj nagłówek do żądania. Poniższy przykład przedstawia Authorization nagłówek dla tej samej operacji:

Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=  

Aby używać autoryzacji klucza współdzielonego 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 Authorization nagłówki, aby używać klucza współużytkowanego zamiast klucza współużytkowanego. Format podpisu wymagany przez klucz udostępniony Lite jest identyczny z wymaganym dla klucza współużytkowanego przez wersje usług obiektów blob i kolejek przed 2009-09-19.

Ważne

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 należy uwzględniać -secondary oznaczenia 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 jest to zero, ustaw Content-Length część StringToSign elementu na 0. Zwykle jest to pusty ciąg.

Na przykład w przypadku następującego żądania wartość nagłówka Content-Length jest uwzględniana nawet wtedy StringToSign , 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

Obiekt 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

Natomiast w wersjach po 2014-02-14 StringToSign element musi zawierać pusty ciąg dla Content-Lengthelementu :

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 tabel (autoryzacja klucza współdzielonego)

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

Ciąg podpisu 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, w tym że nie zawiera CanonicalizedHeaders części ciągu. Ponadto nagłówek w tym przypadku nigdy nie jest pusty, Date nawet jeśli żądanie ustawi x-ms-date nagłówek. Jeśli żądanie ustawia x-ms-datewartość , 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 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;  

Uwaga

Począwszy od wersji 2009-09-19, usługa Table Service wymaga, aby wszystkie wywołania REST zawierały DataServiceVersion nagłówki 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ółdzielonego Lite, aby autoryzować żądanie skierowane do wersji 2009-09-19 i nowszych usług obiektów blob i kolejek oraz w wersji 2014-02-14 i nowszych usług plików.

Ciąg podpisu dla klucza współdzielonego 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, aby używał języka Shared Key Lite bez zmiany samego ciągu podpisu. Korzystając z klucza współdzielonego Lite, nie uzyskasz rozszerzonej funkcjonalności zabezpieczeń udostępnianej przy użyciu klucza udostępnionego w wersji 2009-09-19 i nowszych.

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 Authorization nagłówek i dodaj nagłówek do żądania. Poniższy przykład przedstawia Authorization nagłówek dla tej samej operacji:

Authorization: SharedKeyLite myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=  

Usługa tabel (autoryzacja klucza współdzielonego Lite)

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

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 przedstawiono ciąg podpisu dla operacji Tworzenie 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 Authorization nagłówek, a następnie dodaj nagłówek do żądania. Poniższy przykład przedstawia Authorization nagłówek dla tej samej operacji:

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

Konstruowanie kanonicznego ciągu nagłówków

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

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

  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 pojawić się tylko raz w ciągu.

    Uwaga

    Porządkowanie leksykograficzne może nie zawsze zbiegać się z konwencjonalnym kolejnością alfabetyczną.

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

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

  1. Przycina wszelkie białe znaki wokół dwukropka w nagłówku.

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

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

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

Uwaga

Przed usługą w wersji 2016-05-31 nagłówki z pustymi wartościami zostały pominięte z 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ęść CanonicalizedResource ciągu, która pochodzi 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ółdzielonego 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 udostępniony i klucz wspólny Lite dla wszystkich wersji usługi Table Service oraz klucz udostępniony Lite w wersji 2009-09-19 i nowszej usług obiektów blob i kolejek. Ten format jest identyczny z formatem używanym w poprzednich wersjach usług magazynu.

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

Ważne

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

Uwaga

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

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

Ten format obsługuje autoryzację klucza współdzielonego 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 CanonicalizedResource ciąg 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 w identyfikatorze 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ą name-value.

  8. Dołącz każdą nazwę i wartość parametru zapytania 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 dołącz je do listy rozdzielanej przecinkami:

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

Należy pamiętać 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 musi być używany, upewnij się, że nie ma to 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 CanonicalizedResource część ciągu podpisu, ponieważ może zostać skonstruowana z 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 i nowszych

Ten format obsługuje klucz współużytkowany i klucz wspólny Lite dla wszystkich wersji usługi Table Oraz klucz wspólny Lite w wersji 2009-09-19 i nowszej 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 CanonicalizedResource ciąg 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 comp parametr (na przykład ?comp=metadata). W ciągu zapytania nie należy uwzględniać żadnych innych parametrów.

Kodowanie podpisu

Aby zakodować podpis, wywołaj algorytm HMAC-SHA256 w ciągu podpisu zakodowanym w formacie UTF-8 i zakoduj wynik jako Base64. Pamiętaj, że należy również 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ż