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żne
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
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ż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ć 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.
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).
Uwaga
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
.
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.
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
.
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łówekDate
, niezależnie od tego, czy został określony w żądaniu, i po prostu określić pusty wiersz dla częściDate
ciągu podpisu. W tym przypadku postępuj zgodnie z instrukcjami w Konstruowanie ciągu nagłówków kanonicznych sekcji, aby dodać nagłówekx-ms-date
.Dopuszczalne jest określenie zarówno
x-ms-date
, jak iDate
; w tym przypadku usługa używa wartościx-ms-date
.Jeśli nie określono nagłówka
x-ms-date
, określ nagłówekDate
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
iCanonicalizedResource
tworzących część ciągu podpisu, zobacz odpowiednie sekcje w dalszej części tego tematu.
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ż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 pokazano ciąg podpisu dla operacji get blob
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ż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 oznaczenia -secondary
w nagłówku autoryzacji. W celach autoryzacji nazwa konta jest zawsze nazwą lokalizacji podstawowej, nawet w przypadku dostępu pomocniczego.
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
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;
Uwaga
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.
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
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=
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=
Aby skonstruować część CanonicalizedHeaders
ciągu podpisu, wykonaj następujące kroki:
Pobierz wszystkie nagłówki zasobu rozpoczynającego się od
x-ms-
, w tym nagłówekx-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ą 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.
Przycina wszelkie odstępy wokół dwukropka w nagłówku.
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
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.
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żne
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.
Uwaga
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
.
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:
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
comp
, jeś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ą nazwa-wartość.
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
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
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:
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 parametr
comp
(na przykład?comp=metadata
). W ciągu zapytania nie powinny być uwzględniane żadne inne parametry.
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>)))
- interfejs API REST usługi Blob Service
- interfejs API REST usługi kolejkowania
- interfejs API REST usługi Table Service
- Storage Services REST