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 do publicznego lub podpisanego dostępu. Jedną z opcji autoryzowania żądania jest użycie klucza udostępnionego, opisanego w tym artykule.

Porada

Usługa Azure Storage obsługuje integrację z usługą Azure Active Directory w celu precyzyjnej kontroli dostępu do zasobów magazynu. Integracja usługi Azure AD jest obsługiwana dla usług obiektów Blob i Queue. Ponieważ usługa Azure AD zapewnia zarządzanie tożsamościami, można autoryzować dostęp do zasobów magazynu bez przechowywania kluczy dostępu do konta w aplikacjach, tak jak w kluczu udostępnionym. Aby uzyskać więcej informacji, zobacz Autoryzuj za pomocą usługi Azure Active Directory.

Usługi obiektów blob, queue, table i file obsługują następujące schematy autoryzacji klucza udostępnionego dla wersji 2009-09-19 i nowszej (dla usług obiektów Blob, Queue i Table service) i wersji 2014-02-14 i nowszych (dla usługi plików):

  • Klucz udostępniony dla usług obiektów blob, kolejki i plików. Schemat autoryzacji klucza udostępnionego służy do wysuwu żądań względem usług obiektów Blob, Queue i File. Autoryzacja klucza udostępnionego w wersji 2009-09-19 i nowszych obsługuje rozszerzony ciąg podpisu dla zwiększonych zabezpieczeń i wymaga aktualizacji usługi w celu autoryzacji przy użyciu tego rozszerzonego podpisu.

  • Klucz udostępniony dla usługi tabel. Schemat autoryzacji klucza udostępnionego służy do wysuwu żądań względem usługi Tabel przy użyciu interfejsu API REST. Autoryzacja klucza udostępnionego dla usługi tabeli w wersji 2009-09-19 i później używa tego samego ciągu podpisu, co w poprzednich wersjach usługi Tabela.

  • Wspólny klucz Lite. Schemat autoryzacji Klucz udostępniony Lite służy do wysyłania żądań dotyczących usług obiektów Blob, Queue, Table i File.

    W wersji 2009-09-19 i nowszej usług obiektów Blob i queue autoryzacja shared Key Lite obsługuje przy użyciu ciągu podpisu identyczne z tym, co było obsługiwane dla klucza udostępnionego w poprzednich wersjach usług obiektów Blob i Queue. W związku z tym można użyć Shared Key Lite do żądania dotyczące usług obiektów Blob i queue bez aktualizowania ciągu podpisu.

Autoryzowane żądanie wymaga dwóch nagłówków: x-ms-date nagłówka Authorization Date lub nagłówka i nagłówka. 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 protokół HTTPS, ale zaleca się korzystanie z protokołu HTTPS.

Uwaga

Kontener lub obiekt blob mogą być udostępniane do publicznego dostępu przez ustawienie uprawnień 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że być dostępna dla podpisanego dostępu za pośrednictwem podpisu dostępu współdzielonego; podpis dostępu współdzielonego jest autoryzowany za pośrednictwem innego mechanizmu. Aby uzyskać więcej informacji, zobacz Delegowanie dostępu za pomocą podpisu dostępu współdzielonego.

Określanie nagłówka Data

Wszystkie autoryzowane żądania muszą zawierać sygnaturę czasowa skoordynowanego czasu uniwersalnego (UTC) dla żądania. Sygnaturę czasą można x-ms-date określić w nagłówku lub Date w standardowym nagłówku 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 do czasu, gdy dotrze do usługi. Chroni to przed niektórymi atakami bezpieczeństwa, w tym atakami powtarzania. Gdy to sprawdzenie nie powiedzie się, serwer zwraca kod odpowiedzi 403 (Zabronione).

Uwaga

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

Określanie nagłówka Autoryzacja

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ę pomyślnie tylko względem kontenera lub obiektu blob oznaczonego jako dostęp publiczny lub kontenera, obiektu blob, kolejki lub tabeli, dla których udostępniono podpis dostępu współdzielonego dla dostępu delegowanego.

Aby autoryzować żądanie, należy podpisać żądanie za pomocą klucza dla konta, które tworzy żądanie i przekazać ten podpis w ramach żądania.

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

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

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

Uwaga

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

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

Konstruowanie ciągu podpisu

Sposób konstruowania ciągu podpisu zależy od tej usługi i wersji, na której zezwalasz i używanego schematu autoryzacji. Podczas konstruowania ciągu podpisu należy pamiętać o następujących czynnościach:

  • Część czasownika ciągu jest zleceniem HTTP, takim jak GET lub PUT, i musi być wielką literą.

  • W przypadku autoryzacji klucza udostępnionego dla usług obiektów Blob, Queue i File każdy nagłówek zawarty w ciągu podpisu może pojawić się tylko raz. Jeśli dowolny nagłówek zostanie zduplikowany, usługa zwraca kod stanu 400 (Złe żą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 jako część żądania; w takim przypadku wymagany jest tylko znak nowego wiersza.

  • Jeśli x-ms-date nagłówek jest określony, można Date zignorować nagłówek, niezależnie od tego, czy jest określony w Date żądaniu i po prostu określić pusty wiersz dla części ciągu podpisu. W takim przypadku postępuj zgodnie z instrukcjami w konstruowaniu kanonicznie nagłówki ciąg sekcji dodawania nagłówka. x-ms-date

    Dopuszczalne jest określenie x-ms-date Datezarówno i; w takim przypadku usługa wykorzystuje wartość x-ms-date.

  • Jeśli x-ms-date nagłówek nie jest określony, określ Date nagłówek w ciągu podpisu, bez dołączania nazwy nagłówka.

  • W ciągu podpisu wymagane są wszystkie znaki nowego wiersza (\n).

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

Usługi obiektów Blob, queue i file Services (autoryzacja klucza udostępnionego)

Aby zakodować ciąg podpisu klucza udostępnionego dla żądania względem wersji 2009-09-19 i nowszej usługi obiektów Blob lub Queue oraz wersji 2014-02-14 i nowszej usługi Plik, należy użyć 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 Długość zawartości musi być pustym ciągiem, jeśli długość zawartości żądania wynosi zero. W wersji 2014-02-14 i wcześniejszej długość zawartości została uwzględniona nawet jeśli zero. Zobacz poniżej, aby uzyskać więcej informacji na temat starego zachowania.

W poniższym przykładzie pokazano ciąg podpisu dla operacji Pobierz obiekt blob. W przypadku braku wartości nagłówka określony jest 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 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 zgodnie z utf-8, skonstruuj Authorization nagłówek i dodaj nagłówek do żądania. W poniższym Authorization przykładzie pokazano nagłówek dla tej samej operacji:

Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=  

Aby użyć autoryzacji klucza udostępnionego w wersji 2009-09-19 i nowszych usług obiektów Blob i Queue, należy zaktualizować kod, aby użyć tego rozszerzonego ciągu podpisu.

Jeśli wolisz przeprowadzić migrację kodu do wersji 2009-09-19 lub nowszej z usług obiektów Blob Authorization i queue z najmniejszą możliwą zmianą, możesz zmodyfikować istniejące nagłówki, aby użyć klucza udostępnionego Lite zamiast klucza udostępnionego. Format podpisu wymagany przez shared key lite jest identyczny z formatem wymaganym dla klucza udostępnionego przez wersje usług obiektów Blob i Queue przed 2009-09-19.

Ważne

Jeśli uzyskujesz dostęp do lokalizacji pomocniczej na koncie magazynu, dla którego jest włączona replikacja geograficzna -secondary dostępu do odczytu (RA-GRS), nie należy dołączać oznaczenia w nagłówku autoryzacji. Do celów autoryzacji nazwa konta jest zawsze nazwą lokalizacji podstawowej, nawet dla dostępu pomocniczego.

Nagłówek Długość zawartości w wersji 2014-02-14 i wcześniejszych

W przypadku korzystania z wersji 2014-02-14 lub Content-Length wcześniejszej, StringToSign 0jeśli Content-Length jest zero, należy ustawić część na . Normalnie byłby to pusty ciąg.

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

Jest StringToSign 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

w wersjach po 2014-02-14 StringToSign musi zawierać pusty Content-Lengthciąg dla:

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 tabeli (autoryzacja klucza udostępnionego)

Autoryzacji klucza udostępnionego należy użyć do autoryzacji żądania złożonego w usłudze Tabel, jeśli usługa używa interfejsu API REST do żądania. Format ciągu podpisu dla klucza udostępnionego względem usługi tabel jest taki sam dla wszystkich wersji.

Ciąg podpisu klucza udostępnionego dla żądania względem usługi Tabela różni się nieznacznie od żądania względem CanonicalizedHeaders usługi blob lub queue, ponieważ nie zawiera części ciągu. Ponadto Date nagłówek w tym przypadku nigdy nie jest pusty, nawet jeśli żądanie ustawia x-ms-date nagłówek. Jeśli żądanie x-ms-dateustawia , ta wartość jest również Date używana dla wartości nagłówka.

Aby zakodować ciąg podpisu dla żądania względem usługi Tabele wykonanej przy użyciu interfejsu API REST, należy użyć 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 Tabela DataServiceVersion wymaga, aby wszystkie wywołania REST zawierały nagłówki i. MaxDataServiceVersion Aby uzyskać więcej informacji, zobacz Ustawianie nagłówków wersji usługi danych OData.

Usługi obiektów Blob, Queue i File (autoryzacja klucza udostępnionego lite)

Użytkownik może użyć autoryzacji Shared Key Lite w celu autoryzacji żądania złożonego w wersji 2009-09-19 i nowszej usług obiektów Blob i Queue oraz w wersji 2014-02-14 i nowszej w usługach plików.

Ciąg podpisu dla klucza udostępnionego Lite jest identyczny z ciągiem podpisu wymaganym dla autoryzacji klucza udostępnionego w wersjach usług obiektów Blob i Queue przed 2009-09-19. Więc jeśli chcesz przeprowadzić migrację kodu z najmniejszą liczbą zmian w wersji 2009-09-19 usług obiektów Blob i queue, możesz zmodyfikować kod, aby użyć shared Key Lite, bez zmiany samego ciągu podpisu. Korzystając z funkcji Shared Key Lite, nie uzyskasz rozszerzonych funkcji zabezpieczeń udostępnianych przy użyciu klucza udostępnionego w wersji 2009-09-19 i nowszej.

Aby zakodować ciąg podpisu dla żądania z usługą obiektu 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 pokazano ciąg podpisu dla operacji Put Blob. Należy zauważyć, że wiersz nagłówka Content-MD5 jest pusty. Nagłówki wyświetlane w ciągu są parami 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 zgodnie z utf-8, skonstruuj Authorization nagłówek i dodaj nagłówek do żądania. W poniższym Authorization przykładzie pokazano nagłówek dla tej samej operacji:

Authorization: SharedKeyLite myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=  

Usługa tabeli (autoryzacja klucza udostępnionego lite)

Za pomocą autoryzacji Shared Key Lite można autoryzować żądanie złożone w dowolnej wersji usługi Tabela.

Aby zakodować ciąg podpisu dla żądania względem usługi Tabela przy użyciu shared key lite, należy użyć następującego formatu:

StringToSign = Date + "\n"
               CanonicalizedResource  

W poniższym przykładzie przedstawiono ciąg podpisu dla operacji Utwórz tabelę.

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. W poniższym Authorization przykładzie pokazano 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 dla zasobu, x-ms-które x-ms-date zaczynają się od , w tym nagłówka.

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

  3. Sortuj nagłówki leksykograficznie według nazwy nagłówka w porządku rosnącym. Każdy nagłówek może pojawić się tylko raz w ciągu.

    Uwaga

    Kolejność leksykograficzna nie zawsze pokrywa się z konwencjonalną kolejnością alfabetyczną.

  4. Zastąp dowolny biały spację liniową w wartości nagłówka pojedynczą spacją.

Spacja liniowa obejmuje powrót karetki/posuw liniowy (CRLF), spacje i karty. Szczegółowe informacje można znaleźć w punkcie 4.2 rFC 2616. Nie należy zastępować żadnych odstępów wewnątrz cytowanego ciągu.

  1. Przytnij dowolny biały obszar wokół dwukropka w nagłówku.

  2. Na koniec dołącz znak nowego wiersza do każdego kanonicznego nagłówka na liście wynikowej. Skonstruuj CanonicalizedHeaders ciąg, konkasują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 wersją usługi 2016-05-31 nagłówki z pustymi wartościami zostały pominięte w ciągu podpisu. Są one teraz reprezentowane w CanonicalizedHeaders przez bezpośrednio następujące znak jelita grubego z kończącego się nowego wiersza.

Konstruowanie kanonicznego ciągu zasobu

Część CanonicalizedResource ciągu podpisu reprezentuje zasób usług magazynowania, na który ma odpowiadać żądanie. Każda część CanonicalizedResource ciągu, który pochodzi z identyfikatora URI zasobu powinny być zakodowane dokładnie tak, jak jest w identyfikatorze URI.

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

  • Format, który obsługuje autoryzację klucza udostępnionego dla wersji 2009-09-19 i nowszych usług obiektów Blob i queue oraz dla wersji 2014-02-14 i nowszej usługi Plik.

  • Format, który obsługuje klucz udostępniony i klucz udostępniony Lite dla wszystkich wersji usługi tabeli i Shared Key Lite dla wersji 2009-09-19 i nowsze usług obiektów Blob i Queue. Ten format jest identyczny z formatem używanym w poprzednich wersjach usług magazynu.

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

Ważne

Jeśli konto magazynu jest replikowane za pomocą replikacji geograficznej dostępu do odczytu (RA-GRS) i –secondary uzyskujesz CanonicalizedResource dostęp do zasobu w lokalizacji dodatkowej, nie należy dołączać oznaczenia w ciągu. Identyfikator URI zasobu CanonicalizedResource używany w identyfikatorze URI ciągu powinien być identyfikatorem URI zasobu w lokalizacji podstawowej.

Uwaga

Jeśli autoryzujesz emulator magazynu, nazwa konta pojawi CanonicalizedResource się dwa razy w ciągu. Jest to oczekiwane. Jeśli zezwalasz na usługi magazynu platformy Azure, nazwa konta CanonicalizedResource pojawi się tylko jeden raz w ciągu.

Wspólny format klucza dla 2009-09-19 i nowszych

Ten format obsługuje autoryzację klucza udostępnionego dla wersji 2009-09-19 i nowszych usług obiektów Blob i Queue oraz wersji 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 do przodu (/), a następnie nazwę konta, do której jest dostęp.

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

  3. Pobierz wszystkie parametry kwerendy w identyfikatorze comp URI zasobu, w tym parametr, jeśli istnieje.

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

  5. Sortuj parametry kwerendy leksykograficznie według nazwy parametru w porządku rosnącym.

  6. Adres URL dekoduj każdą nazwę i wartość parametru kwerendy.

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

  8. Dołącz każdą nazwę i wartość parametru kwerendy 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 kwerendy ma więcej niż jedną wartość, posortuj wszystkie wartości leksykograficznie, a następnie dołącz je do listy oddzielonej przecinkami:

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

Należy pamiętać o następujących regułach konstruowania kanonicznego ciągu zasobu:

  • Należy unikać używania znaku nowego wiersza (\n) w wartościach parametrów kwerendy. Jeśli musi być używany, upewnij się, że nie wpływa na format kanonicznego ciągu zasobów.

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

Oto kilka przykładów, CanonicalizedResource które pokazują część ciągu podpisu, ponieważ może być skonstruowany z identyfikatora URI danego żą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

Współdzielony format usługi Key Lite i Table service dla 2009-09-19 i nowszych

Ten format obsługuje klucz udostępniony i klucz udostępniony Lite dla wszystkich wersji usługi Tabela i Shared Key Lite dla wersji 2009-09-19 i nowszych usług obiektów Blob and Queue oraz wersji 2014-02-14 i nowszej usługi Plik. 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 do przodu (/), a następnie nazwę konta, do której jest 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 comp zapytania i parametr ?comp=metadata(na przykład ). Żadne inne parametry nie powinny być uwzględniane w ciągu zapytania.

Kodowanie podpisu

Aby zakodować podpis, wywołaj algorytm HMAC-SHA256 na ciąg podpisu zakodowanym w warstwie UTF-8 i zakoduj wynik jako Base64. Należy również pamiętać, że należy również base64-dekodować klucz konta magazynu. 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ż