Share via

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.

Belangrijk

Voor optimale beveiliging raadt Microsoft aan om waar mogelijk Microsoft Entra ID met beheerde identiteiten te gebruiken om aanvragen voor blob-, wachtrij- en tabelgegevens te autoriseren. Autorisatie met Microsoft Entra ID en beheerde identiteiten biedt superieure beveiliging en gebruiksgemak ten opzichte van autorisatie met gedeelde sleutels. Zie Autoriseren met Microsoft Entra ID voor meer informatie. Zie Wat zijn beheerde identiteiten voor Azure-resources voor meer informatie over beheerde identiteiten.

Voor resources die buiten Azure worden gehost, zoals on-premises toepassingen, kunt u beheerde identiteiten gebruiken via Azure Arc. Apps die worden uitgevoerd op servers met Azure Arc kunnen bijvoorbeeld beheerde identiteiten gebruiken om verbinding te maken met Azure-services. Zie Verifiëren op basis van Azure-resources met servers met Azure Arc voor meer informatie.

Voor scenario's waarin Sas (Shared Access Signatures) wordt gebruikt, raadt Microsoft aan een SAS voor gebruikersdelegering te gebruiken. Een SAS voor gebruikersdelegatie wordt beveiligd met Microsoft Entra referenties in plaats van de accountsleutel. Zie een SAS voor gebruikersdelegering Creatie voor meer informatie over handtekeningen voor gedeelde toegang.

De services Blob, Queue, Table en File 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. Shared Key-autorisatie in versie 2009-09-19 en hoger ondersteunt een uitgebreide handtekeningtekenreeks voor verbeterde beveiliging en vereist dat u uw service bijwerkt om het gebruik van deze uitgebreide handtekening te autoriseren.

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

  • Gedeelde sleutel Lite. Gebruik het Shared Key Lite-autorisatieschema om aanvragen te doen 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 in te voeren 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 ten zeerste aanbevolen.

Notitie

Een container of blob kan beschikbaar worden gesteld 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 shared access signature voor meer informatie.

De datumkoptekst opgeven

Alle geautoriseerde aanvragen moeten het utc-tijdstempel (Coordinated Universal Time) voor de aanvraag bevatten. U kunt de 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 waarop de aanvraag wordt gemaakt.

De opslagservices zorgen ervoor dat een aanvraag niet ouder is dan 15 minuten wanneer deze de service bereikt. Dit beschermt tegen bepaalde beveiligingsaanvallen, waaronder herhalingsaanvallen. 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 in een container of blob die is gemarkeerd voor openbare toegang, of voor een container, blob, wachtrij of tabel waarvoor een shared access signature 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 is berekend met behulp van het SHA256-algoritme en vervolgens 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 maakt, is afhankelijk van de service en versie waarvoor u autorisatie wilt uitvoeren en welk autorisatieschema u gebruikt. Houd bij het samenstellen 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 gedeelde sleutelautorisatie voor de blob-, wachtrij- en bestandsservices kan elke header in de handtekeningtekenreeks slechts eenmaal worden weergegeven. Als een header wordt gedupliceerd, retourneert de service statuscode 400 (Ongeldige aanvraag).

  • De waarden van alle standaard HTTP-headers moeten worden opgenomen in de tekenreeks 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 nieuwe regelteken 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 gecanoniseerde tekenreeks voor kopteksten 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 header niet is opgegeven, geeft u de Date header op in de handtekeningtekenreeks, zonder de headernaam 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 opgenomen die wordt herkend door Azure Storage. Zie de juiste secties verderop in dit onderwerp voor gedetailleerde informatie over het CanonicalizedHeaders samenstellen van de tekenreeks en CanonicalizedResource die deel uitmaken van de handtekeningtekenreeks.

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

Gebruik de volgende indeling om de handtekeningtekenreeks voor een gedeelde sleutel voor een aanvraag te coderen op basis van 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 Content-Length een lege tekenreeks zijn als de inhoudslengte van de aanvraag nul is. In versie 2014-02-14 en eerder is de lengte van de inhoud opgenomen, zelfs als deze nul is. Zie hieronder voor meer informatie over het oude gedrag.

In het volgende voorbeeld ziet u een handtekeningtekenreeks voor een get blob-bewerking . 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 met 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 wachtrijservices 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 voor Shared Key Lite is vereist, is identiek aan de indeling die is vereist voor Gedeelde sleutel door 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 autorisatie-header. 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 is als volgt opgebouwd:

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

In versies na 2014-02-14 moet de StringToSign een lege tekenreeks 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 gedeelde sleutelautorisatie 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 voor de Tabelservice is hetzelfde voor alle versies.

De handtekeningtekenreeks voor een gedeelde sleutel voor een aanvraag voor de Tabelservice wijkt enigszins af van die voor een aanvraag voor de blob- of wachtrijservice, omdat deze niet het CanonicalizedHeaders gedeelte van de tekenreeks 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 is ingesteld x-ms-date, wordt die waarde ook gebruikt voor de waarde van de Date header.

Als u de handtekeningtekenreeks voor een aanvraag voor de Table-service wilt coderen 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 headers van de OData Data Service-versie 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 gedaan 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 wachtrijservices vóór 2009-09-19. Dus als u uw code wilt migreren met zo min mogelijk wijzigingen in versie 2009-09-19 van de blob- en wachtrijservices, 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.

Gebruik de volgende indeling om de handtekeningtekenreeks voor een aanvraag voor de Blob- of Queue-service te coderen:

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

In het volgende voorbeeld ziet u een handtekeningtekenreeks voor een Put Blob-bewerking . Houd er rekening mee dat de koptekstregel 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 met 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=

Tabelservice (Shared Key Lite-autorisatie)

U kunt Shared Key Lite-autorisatie gebruiken om een aanvraag te autoriseren die is gedaan 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 Creatie Table.

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

Codeer deze tekenreeks vervolgens met behulp van het algoritme HMAC-SHA256, maak de Authorization header en voeg vervolgens 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 op voor de resource 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 omvat regelterugloop/regelinvoer (CRLF), spaties en tabs. Zie RFC 2616, sectie 4.2 voor meer informatie. Vervang geen witruimte in een tekenreeks met aanhalingstekens.

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

  2. Voeg ten slotte een nieuw regelteken toe aan elke gecanicaliseerde koptekst in de resulterende lijst. Maak de CanonicalizedHeaders tekenreeks door alle headers in deze lijst samen te brengen in één tekenreeks.

Hieronder ziet u een voorbeeld van een canonicalized headers-tekenreeks:

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 het dubbele punt te volgen met de afsluitende nieuwe regel.

De canonicaliseerde 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 shared key-autorisatie 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 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 wachtrijservices. Deze indeling is identiek aan de indeling die is gebruikt in 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 wordt gebruikt in de CanonicalizedResource tekenreeks-URI 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 in de CanonicalizedResource tekenreeks weergegeven.

Indeling gedeelde sleutel voor 2009-09-19 en hoger

Deze indeling ondersteunt gedeelde sleutelautorisatie 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. Voeg vanaf een lege tekenreeks ("") 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-decoderen van de naam en waarde van elke queryparameter.

  7. Voeg een nieuw regelteken (\n) toe 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 lexicografie 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 gecanoniseerde resourcetekenreeks:

  • Vermijd het gebruik van het nieuwe regelteken (\n) in waarden voor queryparameters. Als deze moet worden gebruikt, controleert u of deze niet van invloed is 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 dit kan worden samengesteld op basis van 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 de indeling die is gebruikt in eerdere versies van de opslagservices. Maak de CanonicalizedResource tekenreeks als volgt in deze indeling:

  1. Voeg vanaf een lege tekenreeks ("") 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 queryreeks toe. De querytekenreeks moet het vraagteken en de comp parameter (bijvoorbeeld ?comp=metadata) bevatten. Er mogen geen andere parameters worden opgenomen in de queryreeks.

De handtekening coderen

Als u de handtekening wilt coderen, roept u het algoritme HMAC-SHA256 aan op de met UTF-8 gecodeerde handtekeningtekenreeks 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