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.
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 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 gecanoniseerde tekenreeks voor kopteksten 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
header niet is opgegeven, geeft u deDate
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 enCanonicalizedResource
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-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
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:
Haal alle headers op voor de resource 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 omvat regelterugloop/regelinvoer (CRLF), spaties en tabs. Zie RFC 2616, sectie 4.2 voor meer informatie. Vervang geen witruimte in een tekenreeks met aanhalingstekens.
Eventuele witruimte rond de dubbele punt in de koptekst knippen.
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:
Blob-service: containers, blobs en metagegevens een naam geven en hiernaar verwijzen
Queue-service: wachtrijserviceresources adresseren
Table-service: 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 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:
Voeg vanaf een lege tekenreeks ("") 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-decoderen van de naam en waarde van elke queryparameter.
Voeg een nieuw regelteken (\n) toe 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 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:
Voeg vanaf een lege tekenreeks ("") 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 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>)))