Autoriseren met gedeelde sleutel

  • Artikel

Elke aanvraag voor een opslagservice moet worden geautoriseerd, tenzij de aanvraag betrekking heeft op een blob- of containerresource die beschikbaar is gesteld voor openbare of ondertekende toegang. Een optie voor het autoriseren van een aanvraag is met behulp van een gedeelde sleutel, zoals beschreven in dit artikel.

Tip

Azure Storage biedt integratie met Microsoft Entra ID voor identiteitsgebaseerde autorisatie van aanvragen voor de blob-, bestands-, wachtrij- en tabelservices. Met Microsoft Entra ID kunt u op rollen gebaseerd toegangsbeheer (RBAC) gebruiken om toegang te verlenen tot blob-, bestands-, wachtrij- en tabelresources aan gebruikers, groepen of toepassingen. Microsoft Entra ID kunt worden gebruikt om toegang tot opslagresources te autoriseren zonder uw accounttoegangssleutels op te slaan in uw toepassingen, zoals u doet met gedeelde sleutel. Zie Autoriseren met Microsoft Entra ID voor meer informatie.

De blob-, wachtrij-, tabel- en bestandsservices ondersteunen de volgende autorisatieschema's voor gedeelde sleutels voor versie 2009-09-19 en hoger (voor blob-, wachtrij- en tabelservice) en versie 2014-02-14 en hoger (voor bestandsservice):

  • Gedeelde sleutel voor blob-, wachtrij- en bestandsservices. Gebruik het autorisatieschema voor gedeelde sleutels om aanvragen te doen voor de blob-, wachtrij- en bestandsservices. Autorisatie van gedeelde sleutels in versie 2009-09-19 en hoger ondersteunt een uitgebreide handtekeningtekenreeks voor verbeterde beveiliging en vereist dat u uw service bijwerkt om te autoriseren met behulp van deze uitgebreide handtekening.

  • Gedeelde sleutel voor Table Service. Gebruik het autorisatieschema voor gedeelde sleutels om aanvragen uit te voeren voor de Table-service met behulp van de REST API. Gedeelde sleutelautorisatie voor de Table-service in versie 2009-09-19 en hoger gebruikt dezelfde handtekeningtekenreeks als in eerdere versies van de Table-service.

  • Gedeelde sleutel Lite. Gebruik het autorisatieschema Shared Key Lite om aanvragen in te voeren voor de blob-, wachtrij-, tabel- en bestandsservices.

    Voor versie 2009-09-19 en hoger van de Blob- en Queue-services ondersteunt Shared Key Lite-autorisatie het gebruik van een handtekeningtekenreeks die identiek is aan wat werd ondersteund voor Gedeelde sleutel in eerdere versies van de blob- en wachtrijservices. U kunt daarom Shared Key Lite gebruiken om aanvragen te doen voor de blob- en wachtrijservices zonder uw handtekeningtekenreeks bij te werken.

Voor een geautoriseerde aanvraag zijn twee headers vereist: de Date of-header x-ms-date en de Authorization header. In de volgende secties wordt beschreven hoe u deze headers maakt.

Belangrijk

Azure Storage ondersteunt zowel HTTP als HTTPS, maar het gebruik van HTTPS wordt sterk aanbevolen.

Notitie

Een container of blob kan beschikbaar worden gemaakt voor openbare toegang door de machtigingen van een container in te stellen. Zie Toegang tot Azure Storage-resources beheren voor meer informatie. Een container, blob, wachtrij of tabel kan beschikbaar worden gesteld voor ondertekende toegang via een shared access signature; een shared access signature wordt geautoriseerd via een ander mechanisme. Zie Toegang delegeren met een handtekening voor gedeelde toegang voor meer informatie.

De datumkoptekst opgeven

Alle geautoriseerde aanvragen moeten de UTC-tijdstempel (Coordinated Universal Time) voor de aanvraag bevatten. U kunt het tijdstempel opgeven in de x-ms-date header of in de standaard HTTP/HTTPS-header Date . Als beide headers zijn opgegeven voor de aanvraag, wordt de waarde van x-ms-date gebruikt als het tijdstip van het maken van de aanvraag.

De opslagservices zorgen ervoor dat een aanvraag niet ouder is dan 15 minuten op het moment dat deze de service bereikt. Dit beschermt tegen bepaalde beveiligingsaanvallen, waaronder replay-aanvallen. Wanneer deze controle mislukt, retourneert de server antwoordcode 403 (verboden).

Notitie

De x-ms-date header wordt opgegeven omdat sommige HTTP-clientbibliotheken en -proxy's de Date header automatisch instellen en de ontwikkelaar niet de mogelijkheid geven om de waarde ervan te lezen om deze op te nemen in de geautoriseerde aanvraag. Als u instelt x-ms-date, maakt u de handtekening met een lege waarde voor de Date koptekst.

De autorisatieheader opgeven

Een geautoriseerde aanvraag moet de Authorization header bevatten. Als deze header niet is opgenomen, is de aanvraag anoniem en slaagt deze alleen voor een container of blob die is gemarkeerd voor openbare toegang, of voor een container, blob, wachtrij of tabel waarvoor een handtekening voor gedeelde toegang is opgegeven voor gedelegeerde toegang.

Als u een aanvraag wilt autoriseren, moet u de aanvraag ondertekenen met de sleutel voor het account dat de aanvraag doet en die handtekening doorgeven als onderdeel van de aanvraag.

De indeling voor de Authorization header is als volgt:

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

waarbij SharedKey of SharedKeyLite de naam is van het autorisatieschema, AccountName de naam is van het account dat de resource aanvraagt en Signature een HMAC (Hash-based Message Authentication Code) die is samengesteld op basis van de aanvraag en wordt berekend met behulp van het SHA256-algoritme en vervolgens is gecodeerd met behulp van Base64-codering.

Notitie

Het is mogelijk om een resource aan te vragen die zich onder een ander account bevindt, als die resource openbaar toegankelijk is.

In de volgende secties wordt beschreven hoe u de Authorization header maakt.

De handtekeningtekenreeks samenstellen

Hoe u de handtekeningtekenreeks samenvoegt, is afhankelijk van de service en versie die u autoriseert en welk autorisatieschema u gebruikt. Houd bij het maken van de handtekeningtekenreeks rekening met het volgende:

  • Het VERB-gedeelte van de tekenreeks is het HTTP-werkwoord, zoals GET of PUT, en moet hoofdletters zijn.

  • Voor autorisatie van gedeelde sleutels voor de blob-, wachtrij- en bestandsservices kan elke header in de handtekeningtekenreeks slechts één keer worden weergegeven. Als een header wordt gedupliceerd, retourneert de service statuscode 400 (Ongeldige aanvraag).

  • De waarden van alle standaard HTTP-headers moeten in de tekenreeks worden opgenomen in de volgorde die wordt weergegeven in de handtekeningindeling, zonder de headernamen. Deze headers kunnen leeg zijn als ze niet worden opgegeven als onderdeel van de aanvraag; in dat geval is alleen het teken voor de nieuwe regel vereist.

  • Als de x-ms-date header is opgegeven, kunt u de Date header negeren, ongeacht of deze is opgegeven in de aanvraag, en gewoon een lege regel opgeven voor het Date gedeelte van de handtekeningtekenreeks. In dit geval volgt u de instructies in de sectie De canonicalized headers-tekenreeks maken om de x-ms-date header toe te voegen.

    Het is acceptabel om zowel als op x-ms-dateDatete geven. In dit geval gebruikt de service de waarde van x-ms-date.

  • Als de x-ms-date koptekst niet is opgegeven, geeft u de Date koptekst op in de handtekeningtekenreeks, zonder de naam van de koptekst op te geven.

  • Alle nieuwe regeltekens (\n) die worden weergegeven, zijn vereist in de handtekeningtekenreeks.

  • De handtekeningtekenreeks bevat canonicalized headers en canonicalized resource strings. Als u deze tekenreeksen canoniseert, worden ze in een standaardindeling gezet die wordt herkend door Azure Storage. Zie de CanonicalizedHeaders juiste secties verderop in dit onderwerp voor gedetailleerde informatie over het samenstellen van de tekenreeks en CanonicalizedResource die deel uitmaken van de handtekeningtekenreeks.

Blob-, wachtrij- en bestandsservices (autorisatie met gedeelde sleutel)

Gebruik de volgende indeling om de handtekeningtekenreeks voor gedeelde sleutels voor een aanvraag te coderen op de versie 2009-09-19 en hoger van de Blob- of Queue-service, en versie 2014-02-14 en hoger van de Bestandsservice:

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;

Belangrijk

In de huidige versie moet het veld Lengte van inhoud een lege tekenreeks zijn als de inhoudslengte van de aanvraag nul is. In versie 2014-02-14 en eerder werd de lengte van de inhoud opgenomen, zelfs als deze nul was. Zie hieronder voor meer informatie over het oude gedrag.

In het volgende voorbeeld ziet u een handtekeningtekenreeks voor een bewerking Blob ophalen . Als er geen headerwaarde is, wordt alleen het nieuwe regelteken opgegeven.

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

Als u dit per regel opsplitst, ziet u elk gedeelte van dezelfde tekenreeks:

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*/

Codeer deze tekenreeks vervolgens met behulp van het algoritme HMAC-SHA256 via de UTF-8-gecodeerde handtekeningtekenreeks, maak de Authorization header en voeg de header toe aan de aanvraag. In het volgende voorbeeld ziet u de Authorization header voor dezelfde bewerking:

Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=

Als u shared key-autorisatie wilt gebruiken met versie 2009-09-19 en hoger van de blob- en wachtrijservices, moet u uw code bijwerken om deze uitgebreide handtekeningtekenreeks te gebruiken.

Als u uw code liever migreert naar versie 2009-09-19 of hoger van de Blob- en Queue-services met zo min mogelijk wijzigingen, kunt u uw bestaande Authorization headers wijzigen om Shared Key Lite te gebruiken in plaats van Gedeelde sleutel. De handtekeningindeling die is vereist voor Shared Key Lite, is identiek aan de indeling die is vereist voor Gedeelde sleutel voor versies van de Blob- en Queue-services van vóór 2009-09-19.

Belangrijk

Als u toegang hebt tot de secundaire locatie in een opslagaccount waarvoor geo-replicatie met leestoegang (RA-GRS) is ingeschakeld, moet u de -secondary aanduiding niet opnemen in de autorisatieheader. Voor autorisatiedoeleinden is de accountnaam altijd de naam van de primaire locatie, zelfs voor secundaire toegang.

Header content-length in versie 2014-02-14 en eerder

Wanneer u versie 2014-02-14 of eerder gebruikt, als Content-Length nul is, stelt u het deel van de Content-LengthStringToSign in op 0. Normaal gesproken is dit een lege tekenreeks.

Voor de volgende aanvraag wordt bijvoorbeeld de waarde van de Content-Length header opgenomen in de StringToSign even wanneer deze nul is.

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

De StringToSign wordt als volgt samengesteld:

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

Terwijl in versies na 2014-02-14, de StringToSign een lege tekenreeks moet bevatten voor 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

Tabelservice (autorisatie van gedeelde sleutel)

U moet autorisatie met een gedeelde sleutel gebruiken om een aanvraag te autoriseren die is ingediend bij de Table-service als uw service de REST API gebruikt om de aanvraag te doen. De indeling van de handtekeningtekenreeks voor Gedeelde sleutel in de Tabelservice is hetzelfde voor alle versies.

De handtekeningtekenreeks voor een gedeelde sleutel voor een aanvraag voor de tabelservice verschilt enigszins van die voor een aanvraag voor de blob- of wachtrijservice, omdat deze CanonicalizedHeaders het gedeelte van de tekenreeks niet bevat. Bovendien is de Date header in dit geval nooit leeg, zelfs niet als de aanvraag de x-ms-date header instelt. Als de aanvraag wordt ingesteld x-ms-date, wordt die waarde ook gebruikt voor de waarde van de Date header.

Als u de handtekeningtekenreeks wilt coderen voor een aanvraag voor de Table-service die is gemaakt met behulp van de REST API, gebruikt u de volgende indeling:

StringToSign = VERB + "\n" +
               Content-MD5 + "\n" +
               Content-Type + "\n" +  
               Date + "\n" +  
               CanonicalizedResource;

Notitie

Vanaf versie 2009-09-19 vereist de Table-service dat alle REST-aanroepen de DataServiceVersion headers en MaxDataServiceVersion bevatten. Zie De OData Data Service-versieheaders instellen voor meer informatie.

Blob-, wachtrij- en bestandsservices (Shared Key Lite-autorisatie)

U kunt Shared Key Lite-autorisatie gebruiken om een aanvraag te autoriseren die is ingediend op basis van de versie 2009-09-19 en hoger van de blob- en wachtrijservices, en versie 2014-02-14 en hoger van de bestandsservices.

De handtekeningtekenreeks voor Shared Key Lite is identiek aan de handtekeningtekenreeks die is vereist voor autorisatie van gedeelde sleutels in versies van de Blob- en Queue-services vóór 2009-09-19. Dus als u uw code met het minste aantal wijzigingen wilt migreren naar versie 2009-09-19 van de Blob- en Queue-services, kunt u uw code wijzigen om Shared Key Lite te gebruiken, zonder de handtekeningtekenreeks zelf te wijzigen. Als u Shared Key Lite gebruikt, krijgt u niet de verbeterde beveiligingsfunctionaliteit die wordt geboden door gedeelde sleutel te gebruiken met versie 2009-09-19 en hoger.

Als u de handtekeningtekenreeks voor een aanvraag wilt coderen voor de Blob- of Queue-service, gebruikt u de volgende indeling:

StringToSign = VERB + "\n" +  
               Content-MD5 + "\n" +  
               Content-Type + "\n" +  
               Date + "\n" +  
               CanonicalizedHeaders +   
               CanonicalizedResource;

In het volgende voorbeeld ziet u een handtekeningtekenreeks voor een put-blobbewerking . Houd er rekening mee dat de kopregel Content-MD5 leeg is. De headers die in de tekenreeks worden weergegeven, zijn naam-waardeparen die aangepaste metagegevenswaarden voor de nieuwe blob opgeven.

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

Codeer deze tekenreeks vervolgens met behulp van het algoritme HMAC-SHA256 via de UTF-8-gecodeerde handtekeningtekenreeks, maak de Authorization header en voeg de header toe aan de aanvraag. In het volgende voorbeeld ziet u de Authorization header voor dezelfde bewerking:

Authorization: SharedKeyLite myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=

Table-service (Shared Key Lite-autorisatie)

U kunt Shared Key Lite-autorisatie gebruiken om een aanvraag te autoriseren die is ingediend voor elke versie van de Table-service.

Als u de handtekeningtekenreeks voor een aanvraag voor de Table-service wilt coderen met behulp van Shared Key Lite, gebruikt u de volgende indeling:

StringToSign = Date + "\n"
               CanonicalizedResource

In het volgende voorbeeld ziet u een handtekeningtekenreeks voor een bewerking Tabel maken .

Sun, 11 Oct 2009 19:52:39 GMT\n/testaccount1/Tables

Vervolgens codeert u deze tekenreeks met behulp van het algoritme HMAC-SHA256, maakt u de Authorization header en voegt u de header toe aan de aanvraag. In het volgende voorbeeld ziet u de Authorization header voor dezelfde bewerking:

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

De gecanoniseerde tekenreeks voor kopteksten samenstellen

Voer de volgende stappen uit om het CanonicalizedHeaders gedeelte van de handtekeningtekenreeks samen te stellen:

  1. Haal alle headers voor de resource op die beginnen met x-ms-, inclusief de x-ms-date header.

  2. Converteer elke HTTP-headernaam naar kleine letters.

  3. Sorteer de kopteksten lexicografisch op kopnaam, in oplopende volgorde. Elke koptekst kan slechts eenmaal in de tekenreeks worden weergegeven.

    Notitie

    Lexicografische volgorde valt mogelijk niet altijd samen met conventionele alfabetische volgorde.

  4. Vervang een lineaire witruimte in de headerwaarde door één spatie.

Lineaire witruimte bevat crlf (regelterugloop/regelinvoer), spaties en tabbladen. Zie RFC 2616, sectie 4.2 voor meer informatie. Vervang geen witruimte in een tekenreeks met aanhalingstekens.

  1. Eventuele spaties rond de dubbele punt in de koptekst knippen.

  2. Voeg ten slotte een nieuw regelteken toe aan elke gecanoniseerde koptekst in de resulterende lijst. Maak de CanonicalizedHeaders tekenreeks door alle kopteksten in deze lijst samen te voegen tot één tekenreeks.

Hieronder ziet u een voorbeeld van een gecanoniseerde tekenreeks voor headers:

x-ms-date:Sat, 21 Feb 2015 00:48:38 GMT\nx-ms-version:2014-02-14\n

Notitie

Vóór serviceversie 2016-05-31 werden headers met lege waarden weggelaten uit de handtekeningtekenreeks. Deze worden nu weergegeven in CanonicalizedHeaders door direct na het dubbele punt met de afsluitende nieuwe regel te volgen.

De canonieke resourcetekenreeks samenstellen

Het CanonicalizedResource deel van de handtekeningtekenreeks vertegenwoordigt de opslagservicesresource waarop de aanvraag is gericht. Elk deel van de CanonicalizedResource tekenreeks dat is afgeleid van de URI van de resource, moet precies zo worden gecodeerd als in de URI.

Er zijn twee ondersteunde indelingen voor de CanonicalizedResource tekenreeks:

  • Een indeling die ondersteuning biedt voor autorisatie van gedeelde sleutels voor versie 2009-09-19 en hoger van de blob- en wachtrijservices, en voor versie 2014-02-14 en hoger van de bestandsservice.

  • Een indeling die ondersteuning biedt voor Gedeelde sleutel en Gedeelde sleutel Lite voor alle versies van de Table-service en Gedeelde sleutel Lite voor versie 2009-09-19 en hoger van de blob- en wachtrijservices. Deze indeling is identiek aan die van eerdere versies van de opslagservices.

Zie een van de volgende onderwerpen voor hulp bij het samenstellen van de URI voor de resource die u opent:

Belangrijk

Als uw opslagaccount wordt gerepliceerd met geo-replicatie met leestoegang (RA-GRS) en u toegang hebt tot een resource op de secundaire locatie, moet u de –secondary aanduiding niet opnemen in de CanonicalizedResource tekenreeks. De resource-URI die in de CanonicalizedResource tekenreeks-URI wordt gebruikt, moet de URI zijn van de resource op de primaire locatie.

Notitie

Als u autoriseert op basis van de opslagemulator, wordt de accountnaam twee keer in de CanonicalizedResource tekenreeks weergegeven. Dit is normaal. Als u toestemming geeft voor Azure Storage-services, wordt de accountnaam slechts één keer weergegeven in de CanonicalizedResource tekenreeks.

Indeling gedeelde sleutel voor 2009-09-19 en hoger

Deze indeling ondersteunt autorisatie van gedeelde sleutels voor de versie 2009-09-19 en hoger van de blob- en wachtrijservices, en de versie 2014-02-14 en hoger van de bestandsservices. Maak de CanonicalizedResource tekenreeks als volgt in deze indeling:

  1. Begin met een lege tekenreeks (""), voeg een slash (/) toe, gevolgd door de naam van het account dat eigenaar is van de resource die wordt geopend.

  2. Voeg het gecodeerde URI-pad van de resource toe, zonder queryparameters.

  3. Haal alle queryparameters op de resource-URI op, inclusief de comp parameter als deze bestaat.

  4. Converteer alle parameternamen naar kleine letters.

  5. Sorteer de queryparameters lexicografisch op parameternaam, in oplopende volgorde.

  6. URL-decodeer elke queryparameternaam en -waarde.

  7. Neem een nieuw regelteken (\n) op vóór elk naam-waardepaar.

  8. Voeg de naam en waarde van elke queryparameter toe aan de tekenreeks in de volgende indeling, waarbij u de dubbele punt (:) tussen de naam en de waarde opneemt:

    parameter-name:parameter-value

  9. Als een queryparameter meer dan één waarde heeft, sorteert u alle waarden lexicografisch en neemt u deze op in een door komma's gescheiden lijst:

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

Houd rekening met de volgende regels voor het samenstellen van de canonicaliseerde resourcetekenreeks:

  • Vermijd het gebruik van het nieuwe regelteken (\n) in waarden voor queryparameters. Als deze moet worden gebruikt, moet u ervoor zorgen dat dit geen invloed heeft op de indeling van de canonicaliseerde resourcetekenreeks.

  • Vermijd het gebruik van komma's in queryparameterwaarden.

Hier volgen enkele voorbeelden van het CanonicalizedResource gedeelte van de handtekeningtekenreeks, omdat deze kan worden samengesteld uit een bepaalde aanvraag-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

Shared Key Lite- en Table-service-indeling voor 2009-09-19 en hoger

Deze indeling ondersteunt Shared Key en Shared Key Lite voor alle versies van de Table-service en Shared Key Lite voor versie 2009-09-19 en hoger van de Blob- en Queue-services en versie 2014-02-14 en hoger van de Bestandsservice. Deze indeling is identiek aan die van eerdere versies van de opslagservices. Maak de CanonicalizedResource tekenreeks als volgt in deze indeling:

  1. Begin met een lege tekenreeks (""), voeg een slash (/) toe, gevolgd door de naam van het account dat eigenaar is van de resource die wordt geopend.

  2. Voeg het gecodeerde URI-pad van de resource toe. Als de aanvraag-URI een onderdeel van de resource adresseert, voegt u de juiste querytekenreeks toe. De querytekenreeks moet het vraagteken en de comp parameter bevatten (bijvoorbeeld ?comp=metadata). Er mogen geen andere parameters worden opgenomen in de querytekenreeks.

De handtekening coderen

Als u de handtekening wilt coderen, roept u het algoritme HMAC-SHA256 op de UTF-8-gecodeerde handtekeningtekenreeks aan en codeert u het resultaat als Base64. Houd er rekening mee dat u ook de sleutel van uw opslagaccount base64 moet decoderen. Gebruik de volgende indeling (weergegeven als pseudocode):

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

Zie ook