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 zapewnia integrację z Tożsamość Microsoft Entra na potrzeby autoryzacji opartej na tożsamościach żądań do usług obiektów blob, plików, kolejek i tabel. Za pomocą Tożsamość Microsoft Entra można użyć kontroli dostępu opartej na rolach (RBAC), aby udzielić dostępu do obiektów blob, plików, kolejek i tabel użytkownikom, grupom lub aplikacjom. Tożsamość Microsoft Entra można użyć autoryzowania dostępu 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ą Tożsamość Microsoft Entra.
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ć udostępniane na potrzeby 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 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 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-dateJeśli nagłówek jest określony, możesz zignorowaćDatenagłówek, niezależnie od tego, czy został określony w żądaniu, i po prostu określić pusty wiersz dlaDateczęś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-datenagłówek.Dopuszczalne jest określenie wartości i
x-ms-dateDate; w tym przypadku usługa używa wartościx-ms-date.x-ms-dateJeśli nagłówek nie zostanie określony, określDatenagłó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
CanonicalizedHeadersciągów iCanonicalizedResourcetworzą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 nowszej 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:
Pobierz wszystkie nagłówki zasobu rozpoczynającego się od
x-ms-, w tymx-ms-datenagłówek.Przekonwertuj każdą nazwę nagłówka HTTP na małe litery.
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ą.
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.
Przycina wszelkie białe znaki wokół dwukropka w nagłówku.
Na koniec dołącz nowy znak wiersza do każdego kanonicznego nagłówka na wyświetlonej liście. Skonstruuj
CanonicalizedHeadersciąg, łącząc wszystkie nagłówki na tej liście w jeden ciąg.
Poniżej przedstawiono przykład ciągu kanonicznych 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:
Usługa blob: nazewnictwo i odwoływanie się do kontenerów, obiektów blob i metadanych
Usługa kolejki: adresowanie zasobów usługi kolejki
Usługa tabel: 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ż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:
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.
Dołącz zakodowaną ścieżkę identyfikatora URI zasobu bez żadnych parametrów zapytania.
Pobierz wszystkie parametry zapytania w identyfikatorze URI zasobu, w tym parametr,
compjeśli istnieje.Przekonwertuj wszystkie nazwy parametrów na małe litery.
Sortuj parametry zapytania leksykograficznie według nazwy parametru w kolejności rosnącej.
Dekoduj adres URL każdej nazwy i wartości parametru zapytania.
Dołącz znak nowego wiersza (\n) przed każdą parą name-value.
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-valueJeś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, które pokazują CanonicalizedResource część ciągu podpisu, ponieważ można ją skonstruować 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:
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.
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
compparametr (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>)))