Autoryzacja przy użyciu klucza wspólnegoAuthorize with Shared Key

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.Every request made against a storage service must be authorized, unless the request is for a blob or container resource that has been made available for public or signed access. Jedną z opcji autoryzowania żądania jest użycie klucza udostępnionego, opisanego w tym artykule.One option for authorizing a request is by using Shared Key, described in this article.

Porada

Usługa Azure Storage obsługuje integrację z usługą Azure Active Directory w celu precyzyjnej kontroli dostępu do zasobów magazynu.Azure Storage supports integration with Azure Active Directory for fine-grained control over access to storage resources. Integracja usługi Azure AD jest obsługiwana dla usług obiektów Blob i Queue.Azure AD integration is supported for the Blob and Queue services. 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.Because Azure AD provides identity management, you can authorize access to storage resources without storing your account access keys in your applications, as you do with Shared Key. Aby uzyskać więcej informacji, zobacz Autoryzuj za pomocą usługi Azure Active Directory.For more information, see Authorize with 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):The Blob, Queue, Table, and File services support the following Shared Key authorization schemes for version 2009-09-19 and later (for Blob, Queue, and Table service) and version 2014-02-14 and later (for File service):

  • Klucz udostępniony dla usług obiektów blob, kolejki i plików.Shared Key for Blob, Queue, and File Services. Schemat autoryzacji klucza udostępnionego służy do wysuwu żądań względem usług obiektów Blob, Queue i File.Use the Shared Key authorization scheme to make requests against the Blob, Queue, and File services. 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.Shared Key authorization in version 2009-09-19 and later supports an augmented signature string for enhanced security and requires that you update your service to authorize using this augmented signature.

  • Klucz udostępniony dla usługi tabel.Shared Key for Table Service. Schemat autoryzacji klucza udostępnionego służy do wysuwu żądań względem usługi Tabel przy użyciu interfejsu API REST.Use the Shared Key authorization scheme to make requests against the Table service using the REST API. 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.Shared Key authorization for the Table service in version 2009-09-19 and later uses the same signature string as in previous versions of the Table service.

  • Wspólny klucz Lite.Shared Key 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.Use the Shared Key Lite authorization scheme to make requests against the Blob, Queue, Table, and File services.

    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.For version 2009-09-19 and later of the Blob and Queue services, Shared Key Lite authorization supports using a signature string identical to what was supported against Shared Key in previous versions of the Blob and Queue services. 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.You can therefore use Shared Key Lite to make requests against the Blob and Queue services without updating your signature string.

Autoryzowane żądanie wymaga dwóch nagłówków: x-ms-date nagłówka Authorization Date lub nagłówka i nagłówka.An authorized request requires two headers: the Date or x-ms-date header and the Authorization header. W poniższych sekcjach opisano sposób konstruowania tych nagłówków.The following sections describe how to construct these headers.

Ważne

Usługa Azure Storage obsługuje zarówno protokół HTTP, jak i protokół HTTPS, ale zaleca się korzystanie z protokołu HTTPS.Azure Storage support both HTTP and HTTPS, but using HTTPS is highly recommended.

Uwaga

Kontener lub obiekt blob mogą być udostępniane do publicznego dostępu przez ustawienie uprawnień kontenera.A container or blob may be made available for public access by setting a container's permissions. Aby uzyskać więcej informacji, zobacz Zarządzanie dostępem do zasobów usługi Azure Storage.For more information, see Manage Access to Azure Storage Resources. 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.A container, blob, queue, or table may be available for signed access via a shared access signature; a shared access signature is authorized through a different mechanism. Aby uzyskać więcej informacji, zobacz Delegowanie dostępu za pomocą podpisu dostępu współdzielonego.See Delegate access with a shared access signature for more details.

Określanie nagłówka DataSpecifying the Date header

Wszystkie autoryzowane żądania muszą zawierać sygnaturę czasowa skoordynowanego czasu uniwersalnego (UTC) dla żądania.All authorized requests must include the Coordinated Universal Time (UTC) timestamp for the request. Sygnaturę czasą można x-ms-date określić w nagłówku lub Date w standardowym nagłówku HTTP/HTTPS.You can specify the timestamp either in the x-ms-date header, or in the standard HTTP/HTTPS Date header. Jeśli oba nagłówki są określone w żądaniu, wartość x-ms-date jest używana jako czas utworzenia żądania.If both headers are specified on the request, the value of x-ms-date is used as the request's time of creation.

Usługi magazynu zapewniają, że żądanie nie jest starsze niż 15 minut do czasu, gdy dotrze do usługi.The storage services ensure that a request is no older than 15 minutes by the time it reaches the service. Chroni to przed niektórymi atakami bezpieczeństwa, w tym atakami powtarzania.This guards against certain security attacks, including replay attacks. Gdy to sprawdzenie nie powiedzie się, serwer zwraca kod odpowiedzi 403 (Zabronione).When this check fails, the server returns response code 403 (Forbidden).

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.The x-ms-date header is provided because some HTTP client libraries and proxies automatically set the Date header, and do not give the developer an opportunity to read its value in order to include it in the authorized request. Jeśli ustawisz, x-ms-dateskonstruuj Date podpis z pustą wartością nagłówka.If you set x-ms-date, construct the signature with an empty value for the Date header.

Określanie nagłówka AutoryzacjaSpecifying the Authorization header

Autoryzowane żądanie musi zawierać Authorization nagłówek.An authorized request must include the Authorization header. 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.If this header is not included, the request is anonymous and may only succeed against a container or blob that is marked for public access, or against a container, blob, queue, or table for which a shared access signature has been provided for delegated access.

Aby autoryzować żądanie, należy podpisać żądanie za pomocą klucza dla konta, które tworzy żądanie i przekazać ten podpis w ramach żądania.To authorize a request, you must sign the request with the key for the account that is making the request and pass that signature as part of the request.

Format nagłówka Authorization jest następujący:The format for the Authorization header is as follows:

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.where SharedKey or SharedKeyLite is the name of the authorization scheme, AccountName is the name of the account requesting the resource, and Signature is a Hash-based Message Authentication Code (HMAC) constructed from the request and computed by using the SHA256 algorithm, and then encoded by using Base64 encoding.

Uwaga

Istnieje możliwość żądania zasobu, który znajduje się pod innym kontem, jeśli ten zasób jest publicznie dostępny.It is possible to request a resource that resides beneath a different account, if that resource is publicly accessible.

W poniższych sekcjach opisano Authorization sposób konstruowania nagłówka.The following sections describe how to construct the Authorization header.

Konstruowanie ciągu podpisuConstructing the signature string

Sposób konstruowania ciągu podpisu zależy od tej usługi i wersji, na której zezwalasz i używanego schematu autoryzacji.How you construct the signature string depends on which service and version you are authorizing against and which authorization scheme you are using. Podczas konstruowania ciągu podpisu należy pamiętać o następujących czynnościach:When constructing the signature string, keep in mind the following:

  • Część czasownika ciągu jest zleceniem HTTP, takim jak GET lub PUT, i musi być wielką literą.The VERB portion of the string is the HTTP verb, such as GET or PUT, and must be uppercase.

  • 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.For Shared Key authorization for the Blob, Queue, and File services, each header included in the signature string may appear only once. Jeśli dowolny nagłówek zostanie zduplikowany, usługa zwraca kod stanu 400 (Złe żądanie).If any header is duplicated, the service returns status code 400 (Bad Request).

  • 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.The values of all standard HTTP headers must be included in the string in the order shown in the signature format, without the header names. Te nagłówki mogą być puste, jeśli nie są określone jako część żądania; w takim przypadku wymagany jest tylko znak nowego wiersza.These headers may be empty if they are not being specified as part of the request; in that case, only the new-line character is required.

  • 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.If the x-ms-date header is specified, you may ignore the Date header, regardless of whether it is specified on the request, and simply specify an empty line for the Date portion of the signature string. W takim przypadku postępuj zgodnie z instrukcjami w konstruowaniu kanonicznie nagłówki ciąg sekcji dodawania nagłówka. x-ms-dateIn this case, follow the instructions in the Constructing the canonicalized headers string section for adding the x-ms-date header.

    Dopuszczalne jest określenie x-ms-date Datezarówno i; w takim przypadku usługa wykorzystuje wartość x-ms-date.It is acceptable to specify both x-ms-date and Date; in this case, the service uses the value of 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.If the x-ms-date header is not specified, specify the Date header in the signature string, without including the header name.

  • W ciągu podpisu wymagane są wszystkie znaki nowego wiersza (\n).All new-line characters (\n) shown are required within the signature string.

  • Ciąg podpisu zawiera kanonicznie kanonicznie nagłówki i kanoniczne ciągi zasobów.The signature string includes canonicalized headers and canonicalized resource strings. Canonicalizing tych ciągów umieszcza je w standardowym formacie, który jest rozpoznawany przez usługę Azure Storage.Canonicalizing these strings puts them into a standard format that is recognized by 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.For detailed information on constructing the CanonicalizedHeaders and CanonicalizedResource strings that make up part of the signature string, see the appropriate sections later in this topic.

Usługi obiektów Blob, queue i file Services (autoryzacja klucza udostępnionego)Blob, Queue, and File Services (Shared Key authorization)

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:To encode the Shared Key signature string for a request against the 2009-09-19 version and later of the Blob or Queue service, and version 2014-02-14 and later of the File service, use the following format:

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.In the current version, the Content-Length field must be an empty string if the content length of the request is zero. W wersji 2014-02-14 i wcześniejszej długość zawartości została uwzględniona nawet jeśli zero.In version 2014-02-14 and earlier, the content length was included even if zero. Zobacz poniżej, aby uzyskać więcej informacji na temat starego zachowania.See below for more information on the old behavior.

W poniższym przykładzie pokazano ciąg podpisu dla operacji Pobierz obiekt blob.The following example shows a signature string for a Get Blob operation. W przypadku braku wartości nagłówka określony jest tylko znak nowego wiersza.Where there is no header value, the new-line character only is specified.

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:Breaking this down line-by-line shows each portion of the same string:

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.Next, encode this string by using the HMAC-SHA256 algorithm over the UTF-8-encoded signature string, construct the Authorization header, and add the header to the request. W poniższym Authorization przykładzie pokazano nagłówek dla tej samej operacji:The following example shows the Authorization header for the same operation:

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.To use Shared Key authorization with version 2009-09-19 and later of the Blob and Queue services, you must update your code to use this augmented signature string.

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.If you prefer to migrate your code to version 2009-09-19 or later of the Blob and Queue services with the fewest possible changes, you can modify your existing Authorization headers to use Shared Key Lite instead of Shared Key. 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.The signature format required by Shared Key Lite is identical to that required for Shared Key by versions of the Blob and Queue services prior to 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.If you are accessing the secondary location in a storage account for which read-access geo-replication (RA-GRS) is enabled, do not include the -secondary designation in the authorization header. Do celów autoryzacji nazwa konta jest zawsze nazwą lokalizacji podstawowej, nawet dla dostępu pomocniczego.For authorization purposes, the account name is always the name of the primary location, even for secondary access.

Nagłówek Długość zawartości w wersji 2014-02-14 i wcześniejszychContent-Length header in version 2014-02-14 and earlier

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 .When using version 2014-02-14 or earlier, if Content-Length is zero, then set the Content-Length part of the StringToSign to 0. Normalnie byłby to pusty ciąg.Normally this would be an empty string.

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.For example, for the following request, the value of the Content-Length header is included in the StringToSign even when it is 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:The StringToSign is constructed as follows:

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:Whereas in versions after to 2014-02-14, the StringToSign must contain an empty string for 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 tabeli (autoryzacja klucza udostępnionego)Table service (Shared Key authorization)

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.You must use Shared Key authorization to authorize a request made against the Table service if your service is using the REST API to make the request. Format ciągu podpisu dla klucza udostępnionego względem usługi tabel jest taki sam dla wszystkich wersji.The format of the signature string for Shared Key against the Table service is the same for all versions.

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.The Shared Key signature string for a request against the Table service differs slightly from that for a request against the Blob or Queue service, in that it does not include the CanonicalizedHeaders portion of the string. Ponadto Date nagłówek w tym przypadku nigdy nie jest pusty, nawet jeśli żądanie ustawia x-ms-date nagłówek.Additionally, the Date header in this case is never empty even if the request sets the x-ms-date header. Jeśli żądanie x-ms-dateustawia , ta wartość jest również Date używana dla wartości nagłówka.If the request sets x-ms-date, that value is also used for the value of the Date header.

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:To encode the signature string for a request against the Table service made using the REST API, use the following format:

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. MaxDataServiceVersionBeginning with version 2009-09-19, the Table service requires that all REST calls include the DataServiceVersion and MaxDataServiceVersion headers. Aby uzyskać więcej informacji, zobacz Ustawianie nagłówków wersji usługi danych OData.See Setting the OData Data Service Version Headers for more information.

Usługi obiektów Blob, Queue i File (autoryzacja klucza udostępnionego lite)Blob, Queue, and File services (Shared Key Lite authorization)

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.You may use Shared Key Lite authorization to authorize a request made against the 2009-09-19 version and later of the Blob and Queue services, and version 2014-02-14 and later of the File services.

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.The signature string for Shared Key Lite is identical to the signature string required for Shared Key authorization in versions of the Blob and Queue services prior to 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.So if you wish to migrate your code with the least number of changes to version 2009-09-19 of the Blob and Queue services, you can modify your code to use Shared Key Lite, without changing the signature string itself. 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.By using Shared Key Lite, you will not gain the enhanced security functionality provided by using Shared Key with version 2009-09-19 and later.

Aby zakodować ciąg podpisu dla żądania z usługą obiektu Blob lub Queue, użyj następującego formatu:To encode the signature string for a request against the Blob or Queue service, use the following format:

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.The following example shows a signature string for a Put Blob operation. Należy zauważyć, że wiersz nagłówka Content-MD5 jest pusty.Note that the Content-MD5 header line is empty. Nagłówki wyświetlane w ciągu są parami nazwa-wartość, które określają niestandardowe wartości metadanych dla nowego obiektu blob.The headers shown in the string are name-value pairs that specify custom metadata values for the new 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.Next, encode this string by using the HMAC-SHA256 algorithm over the UTF-8-encoded signature string, construct the Authorization header, and add the header to the request. W poniższym Authorization przykładzie pokazano nagłówek dla tej samej operacji:The following example shows the Authorization header for the same operation:

Authorization: SharedKeyLite myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=  

Usługa tabeli (autoryzacja klucza udostępnionego lite)Table service (Shared Key Lite authorization)

Za pomocą autoryzacji Shared Key Lite można autoryzować żądanie złożone w dowolnej wersji usługi Tabela.You can use Shared Key Lite authorization to authorize a request made against any version of the Table service.

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:To encode the signature string for a request against the Table service using Shared Key Lite, use the following format:

StringToSign = Date + "\n"
               CanonicalizedResource  

W poniższym przykładzie przedstawiono ciąg podpisu dla operacji Utwórz tabelę.The following example shows a signature string for a Create Table operation.

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.Next, encode this string by using the HMAC-SHA256 algorithm, construct the Authorization header, and then add the header to the request. W poniższym Authorization przykładzie pokazano nagłówek dla tej samej operacji:The following example shows the Authorization header for the same operation:

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

Konstruowanie kanonicznego ciągu nagłówkówConstructing the canonicalized headers string

Aby utworzyć CanonicalizedHeaders część ciągu podpisu, wykonaj następujące kroki:To construct the CanonicalizedHeaders portion of the signature string, follow these steps:

  1. Pobierz wszystkie nagłówki dla zasobu, x-ms-które x-ms-date zaczynają się od , w tym nagłówka.Retrieve all headers for the resource that begin with x-ms-, including the x-ms-date header.

  2. Konwertuj każdą nazwę nagłówka HTTP na małe litery.Convert each HTTP header name to lowercase.

  3. Sortuj nagłówki leksykograficznie według nazwy nagłówka w porządku rosnącym.Sort the headers lexicographically by header name, in ascending order. Każdy nagłówek może pojawić się tylko raz w ciągu.Each header may appear only once in the string.

    Uwaga

    Kolejność leksykograficzna nie zawsze pokrywa się z konwencjonalną kolejnością alfabetyczną.Lexicographical ordering may not always coincide with conventional alphabetical ordering.

  4. Zastąp dowolny biały spację liniową w wartości nagłówka pojedynczą spacją.Replace any linear whitespace in the header value with a single space.

Spacja liniowa obejmuje powrót karetki/posuw liniowy (CRLF), spacje i karty.Linear whitespace includes carriage return/line feed (CRLF), spaces, and tabs. Szczegółowe informacje można znaleźć w punkcie 4.2 rFC 2616.See RFC 2616, section 4.2 for details. Nie należy zastępować żadnych odstępów wewnątrz cytowanego ciągu.Do not replace any whitespace inside a quoted string.

  1. Przytnij dowolny biały obszar wokół dwukropka w nagłówku.Trim any whitespace around the colon in the header.

  2. Na koniec dołącz znak nowego wiersza do każdego kanonicznego nagłówka na liście wynikowej.Finally, append a new-line character to each canonicalized header in the resulting list. Skonstruuj CanonicalizedHeaders ciąg, konkasując wszystkie nagłówki na tej liście w jeden ciąg.Construct the CanonicalizedHeaders string by concatenating all headers in this list into a single string.

Poniżej przedstawiono przykład kanonicznego ciągu nagłówków:The following shows an example of a canonicalized headers string:

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.Prior to service version 2016-05-31, headers with empty values were omitted from the signature string. Są one teraz reprezentowane w CanonicalizedHeaders przez bezpośrednio następujące znak jelita grubego z kończącego się nowego wiersza.These are now represented in CanonicalizedHeaders by immediately following the colon character with the terminating new-line.

Konstruowanie kanonicznego ciągu zasobuConstructing the canonicalized resource string

Część CanonicalizedResource ciągu podpisu reprezentuje zasób usług magazynowania, na który ma odpowiadać żądanie.The CanonicalizedResource part of the signature string represents the storage services resource targeted by the request. Każda część CanonicalizedResource ciągu, który pochodzi z identyfikatora URI zasobu powinny być zakodowane dokładnie tak, jak jest w identyfikatorze URI.Any portion of the CanonicalizedResource string that is derived from the resource's URI should be encoded exactly as it is in the URI.

Istnieją dwa obsługiwane formaty CanonicalizedResource dla ciągu:There are two supported formats for the CanonicalizedResource string:

  • 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.A format that supports Shared Key authorization for version 2009-09-19 and later of the Blob and Queue services, and for version 2014-02-14 and later of the File service.

  • 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.A format that supports Shared Key and Shared Key Lite for all versions of the Table service, and Shared Key Lite for version 2009-09-19 and later of the Blob and Queue services. Ten format jest identyczny z formatem używanym w poprzednich wersjach usług magazynu.This format is identical to that used with previous versions of the storage services.

Aby uzyskać pomoc dotyczącą konstruowania identyfikatora URI dla zasobu, do którego uzyskujesz dostęp, zobacz jeden z następujących tematów:For help constructing the URI for the resource you are accessing, see one of the following topics:

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.If your storage account is replicated with read-access geo-replication (RA-GRS), and you are accessing a resource in the secondary location, do not include the –secondary designation in the CanonicalizedResource string. Identyfikator URI zasobu CanonicalizedResource używany w identyfikatorze URI ciągu powinien być identyfikatorem URI zasobu w lokalizacji podstawowej.The resource URI used in the CanonicalizedResource string URI should be the URI of the resource at the primary location.

Uwaga

Jeśli autoryzujesz emulator magazynu, nazwa konta pojawi CanonicalizedResource się dwa razy w ciągu.If you are authorizing against the storage emulator, the account name will appear twice in the CanonicalizedResource string. Jest to oczekiwane.This is expected. Jeśli zezwalasz na usługi magazynu platformy Azure, nazwa konta CanonicalizedResource pojawi się tylko jeden raz w ciągu.If you are authorizing against Azure storage services, the account name will appear only one time in the CanonicalizedResource string.

Wspólny format klucza dla 2009-09-19 i nowszychShared Key format for 2009-09-19 and later

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.This format supports Shared Key authorization for the 2009-09-19 version and later of the Blob and Queue services, and the 2014-02-14 version and later of the File services. Skonstruuj CanonicalizedResource ciąg w tym formacie w następujący sposób:Construct the CanonicalizedResource string in this format as follows:

  1. Począwszy od pustego ciągu (""), dołącz ukośnik do przodu (/), a następnie nazwę konta, do której jest dostęp.Beginning with an empty string (""), append a forward slash (/), followed by the name of the account that owns the resource being accessed.

  2. Dołącz zakodowaną ścieżkę URI zasobu bez żadnych parametrów kwerendy.Append the resource's encoded URI path, without any query parameters.

  3. Pobierz wszystkie parametry kwerendy w identyfikatorze comp URI zasobu, w tym parametr, jeśli istnieje.Retrieve all query parameters on the resource URI, including the comp parameter if it exists.

  4. Konwertuj wszystkie nazwy parametrów na małe litery.Convert all parameter names to lowercase.

  5. Sortuj parametry kwerendy leksykograficznie według nazwy parametru w porządku rosnącym.Sort the query parameters lexicographically by parameter name, in ascending order.

  6. Adres URL dekoduj każdą nazwę i wartość parametru kwerendy.URL-decode each query parameter name and value.

  7. Dołącz znak nowego wiersza (\n) przed każdą parą nazwa-wartość.Include a new-line character (\n) before each name-value pair.

  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ą:Append each query parameter name and value to the string in the following format, making sure to include the colon (:) between the name and the value:

    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:If a query parameter has more than one value, sort all values lexicographically, then include them in a comma-separated list:

    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:Keep in mind the following rules for constructing the canonicalized resource string:

  • Należy unikać używania znaku nowego wiersza (\n) w wartościach parametrów kwerendy.Avoid using the new-line character (\n) in values for query parameters. Jeśli musi być używany, upewnij się, że nie wpływa na format kanonicznego ciągu zasobów.If it must be used, ensure that it does not affect the format of the canonicalized resource string.

  • Unikaj używania przecinków w wartościach parametrów kwerendy.Avoid using commas in query parameter values.

Oto kilka przykładów, CanonicalizedResource które pokazują część ciągu podpisu, ponieważ może być skonstruowany z identyfikatora URI danego żądania:Here are some examples that show the CanonicalizedResource portion of the signature string, as it may be constructed from a given request URI:

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 nowszychShared Key Lite and Table service format for 2009-09-19 and later

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.This format supports Shared Key and Shared Key Lite for all versions of the Table service, and Shared Key Lite for version 2009-09-19 and later of the Blob and Queue services and version 2014-02-14 and later of the File service. Ten format jest identyczny z formatem używanym w poprzednich wersjach usług magazynu.This format is identical to that used with previous versions of the storage services. Skonstruuj CanonicalizedResource ciąg w tym formacie w następujący sposób:Construct the CanonicalizedResource string in this format as follows:

  1. Począwszy od pustego ciągu (""), dołącz ukośnik do przodu (/), a następnie nazwę konta, do której jest dostęp.Beginning with an empty string (""), append a forward slash (/), followed by the name of the account that owns the resource being accessed.

  2. Dołącz zakodowaną ścieżkę identyfikatora URI zasobu.Append the resource's encoded URI path. Jeśli identyfikator URI żądania adresuje składnik zasobu, dołącz odpowiedni ciąg zapytania.If the request URI addresses a component of the resource, append the appropriate query string. Ciąg zapytania powinien zawierać znak comp zapytania i parametr ?comp=metadata(na przykład ).The query string should include the question mark and the comp parameter (for example, ?comp=metadata). Żadne inne parametry nie powinny być uwzględniane w ciągu zapytania.No other parameters should be included on the query string.

Kodowanie podpisuEncoding the signature

Aby zakodować podpis, wywołaj algorytm HMAC-SHA256 na ciąg podpisu zakodowanym w warstwie UTF-8 i zakoduj wynik jako Base64.To encode the signature, call the HMAC-SHA256 algorithm on the UTF-8-encoded signature string and encode the result as Base64. Należy również pamiętać, że należy również base64-dekodować klucz konta magazynu.Note that you also need to Base64-decode your storage account key. Użyj następującego formatu (pokazanego jako pseudokod):Use the following format (shown as pseudocode):

Signature=Base64(HMAC-SHA256(UTF8(StringToSign), Base64.decode(<your_azure_storage_account_shared_key>)))  

Zobacz teżSee also