Autoriseren met gedeelde sleutel
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 deDate
header negeren, ongeacht of deze is opgegeven in de aanvraag, en gewoon een lege regel opgeven voor hetDate
gedeelte van de handtekeningtekenreeks. In dit geval volgt u de instructies in de sectie De canonicalized headers-tekenreeks maken om dex-ms-date
header toe te voegen.Het is acceptabel om zowel als op
x-ms-date
Date
te geven. In dit geval gebruikt de service de waarde vanx-ms-date
.Als de
x-ms-date
koptekst niet is opgegeven, geeft u deDate
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 enCanonicalizedResource
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-Length
StringToSign
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:
Haal alle headers voor de resource op die beginnen met
x-ms-
, inclusief dex-ms-date
header.Converteer elke HTTP-headernaam naar kleine letters.
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.
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.
Eventuele spaties rond de dubbele punt in de koptekst knippen.
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:
Blob-service: containers, blobs en metagegevens een naam geven en hiernaar verwijzen
Queue-service: Wachtrijserviceresources adresseren
Tabelservice: Resources van de tabelservice adresseren
Bestandsservice: shares, mappen, bestanden en metagegevens een naam geven en hiernaar verwijzen
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:
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.
Voeg het gecodeerde URI-pad van de resource toe, zonder queryparameters.
Haal alle queryparameters op de resource-URI op, inclusief de
comp
parameter als deze bestaat.Converteer alle parameternamen naar kleine letters.
Sorteer de queryparameters lexicografisch op parameternaam, in oplopende volgorde.
URL-decodeer elke queryparameternaam en -waarde.
Neem een nieuw regelteken (\n) op vóór elk naam-waardepaar.
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
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:
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.
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>)))