Autoryzacja przy użyciu klucza wspólnego
Każde żądanie dotyczące 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żne
W celu zapewnienia optymalnego bezpieczeństwa firma Microsoft zaleca używanie Tożsamość Microsoft Entra z tożsamościami zarządzanymi w celu autoryzowania żądań względem danych obiektów blob, kolejek i tabel, jeśli jest to możliwe. Autoryzacja przy użyciu Tożsamość Microsoft Entra 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 Autoryzowanie za pomocą Tożsamość Microsoft Entra. Aby dowiedzieć się więcej na temat tożsamości 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 działające 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 względem zasobów platformy Azure za pomocą 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żytkownika. Sygnatura dostępu współdzielonego delegowania użytkownika jest zabezpieczona przy użyciu poświadczeń Microsoft Entra zamiast klucza konta. Aby dowiedzieć się więcej o sygnaturach dostępu współdzielonego, zobacz Twórca sygnatury dostępu współdzielonego delegowania użytkownika.
Usługi blob, Queue, Table i File obsługują następujące schematy autoryzacji klucza współużytkowanego dla wersji 2009-09-19 i nowszych (dla usługi Blob, Queue i Table) oraz w wersji 2014-02-14 lub nowszej (dla usługi plików):
Klucz wspólny dla usług obiektów blob, kolejek i 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 zwiększenia bezpieczeństwa i wymaga zaktualizowania usługi w celu autoryzowania przy użyciu tego rozszerzonego podpisu.
Klucz wspólny dla usługi Table Service. Użyj schematu autoryzacji klucza współużytkowanego, 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 i nowszych 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 obsługiwanym kluczem udostępnionym 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 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 i nagłówka Authorization . W poniższych sekcjach opisano sposób konstruowania tych nagłówków.
Ważne
Usługa Azure Storage obsługuje zarówno protokół HTTP, jak i HTTPS, ale korzystanie z protokołu HTTPS jest zdecydowanie zalecane.
Uwaga
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 można udostępnić na potrzeby 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 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 do 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).
Uwaga
Nagłówek x-ms-date jest udostępniany, 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 jej w autoryzowanym żądaniu. Jeśli ustawisz wartość x-ms-date, 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 dla 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 oparty na skrótach kod uwierzytelniania komunikatów (HMAC) skonstruowany z żądania i obliczany przy użyciu algorytmu SHA256, a następnie zakodowany przy użyciu kodowania Base64.
Uwaga
Istnieje możliwość zażądania zasobu znajdującego się poniżej innego konta, 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 autoryzowania oraz od używanego schematu autoryzacji. Podczas tworzenia ciągu podpisu należy pamiętać o następujących kwestiach:
Część VERB ciągu jest czasownikiem HTTP, takim jak GET lub PUT, i musi mieć wielkie litery.
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 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. Te nagłówki 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 jest określony w żądaniu, i po prostu określić pusty wiersz dlaDateczęści ciągu podpisu. W takim przypadku postępuj zgodnie z instrukcjami w sekcji Tworzenie kanonicznych ciągów nagłówków w celu dodania nagłówkax-ms-date.Dopuszczalne jest określenie parametru 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 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 Service oraz w wersji 2014-02-14 lub 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 starszych 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 operacji Pobierania obiektu 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
Podzielenie tego wiersza 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żyć autoryzacji klucza współużytkowanego w wersji 2009-09-19 lub nowszej usług 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 najmniejszą liczbą możliwych zmian, możesz zmodyfikować istniejące Authorization nagłówki, aby używać klucza wspólnego Lite zamiast klucza wspólnego. Format podpisu wymagany przez klucz wspólny Lite jest identyczny z formatem 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 dołączaj -secondary oznaczenia do nagłówka 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ęść elementu StringToSign na 0wartość . Zwykle jest to pusty ciąg.
Na przykład w przypadku następującego żądania wartość nagłówka Content-Length jest uwzględniana nawet StringToSign 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
Element 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 ciąg 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)
Aby autoryzować żądanie względem usługi Table Service, musisz użyć autoryzacji klucza współużytkowanego, jeśli usługa używa interfejsu API REST do wykonania żądania. Format ciągu podpisu dla klucza współużytkowanego w usłudze 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 w przypadku żądania względem usługi Blob lub Queue Service, ponieważ nie zawiera CanonicalizedHeaders części ciągu.
Date Ponadto nagłówek w tym przypadku nigdy nie jest pusty, nawet jeśli żądanie ustawia x-ms-date nagłówek. Jeśli żądanie ustawi 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 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;
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ólnego Lite)
Możesz użyć autoryzacji klucza wspólnego 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ólnego Lite jest identyczny z ciągiem podpisu wymaganym do autoryzacji klucza współdzielonego w wersjach usług Blob i Queue services przed 2009-09-19. Dlatego jeśli 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ł wspólnego klucza Lite, bez zmiany samego ciągu podpisu. Korzystając z klucza wspólnego Lite, nie uzyskasz ulepszonej funkcjonalności zabezpieczeń udostępnianej przy użyciu klucza wspólnego w wersji 2009-09-19 i nowszych.
Aby zakodować ciąg podpisu dla żądania względem usługi Blob lub Queue Service, użyj następującego formatu:
StringToSign = VERB + "\n" +
Content-MD5 + "\n" +
Content-Type + "\n" +
Date + "\n" +
CanonicalizedHeaders +
CanonicalizedResource;
W poniższym przykładzie pokazano ciąg podpisu operacji Put Blob . Zwróć uwagę, że wiersz nagłówka Content-MD5 jest pusty. Nagłówki wyświetlane w ciągu to pary nazwa-wartość, 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 Table Service (autoryzacja klucza współużytkowanego w wersji Lite)
Możesz użyć autoryzacji klucza wspólnego Lite, aby autoryzować żądanie dotyczące 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 Twórca Table.
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 ciągu nagłówków kanonicznych
Aby utworzyć CanonicalizedHeaders część ciągu podpisu, wykonaj następujące kroki:
Pobierz wszystkie nagłówki zasobu rozpoczynającego się od , łącznie z
x-ms-nagłówkiemx-ms-date.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 być wyświetlany tylko raz w ciągu.
Uwaga
Porządkowanie leksykograficzne może nie zawsze pokrywać się z konwencjonalnym porządkowanie alfabetycznym.
Zastąp wszelkie liniowe odstępy w wartości nagłówka pojedynczą spacją.
Białe znaki liniowe obejmują znak powrotu karetki/linii (CRLF), spacje i karty. Aby uzyskać szczegółowe informacje , zobacz RFC 2616, sekcja 4.2 . Nie zamieniaj żadnych białych znaków wewnątrz cudzysłów.
Przycinaj wszelkie białe znaki wokół dwukropka w nagłówku.
Na koniec dołącz znak nowego wiersza do każdego nagłówka kanonicznego 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 nagłówków kanonicznych:
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 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ęść CanonicalizedResource ciągu pochodząca z identyfikatora URI zasobu powinna być zakodowana dokładnie tak, jak w identyfikatorze URI.
Istnieją dwa obsługiwane formaty dla CanonicalizedResource ciągu:
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 lub nowszej usługi Plików.
Format obsługujący klucz wspólny i klucz wspólny Lite dla wszystkich wersji usługi Table Service 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 kolejki: adresowanie zasobów usługi kolejki
Usługa table: rozwiązywanie problemów z zasobami 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 przy użyciu replikacji geograficznej z dostępem do odczytu (RA-GRS) i uzyskujesz dostęp do zasobu w lokalizacji pomocniczej, nie uwzględniaj –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ługi Azure Storage, nazwa konta będzie wyświetlana tylko raz w CanonicalizedResource ciągu.
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 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 dla identyfikatora 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.
W adresie URL dekoduj każdą nazwę i wartość parametru zapytania.
Dołącz znak nowego wiersza (\n) przed każdą parą nazwa-wartość.
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 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 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ć 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 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 nowszych usług obiektów blob i kolejek oraz w wersji 2014-02-14 lub 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 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 klucz konta magazynu należy zdekodować za pomocą algorytmu Base64. Użyj następującego formatu (pokazanego jako pseudokod):
Signature=Base64(HMAC-SHA256(UTF8(StringToSign), Base64.decode(<your_azure_storage_account_shared_key>)))