Dienst-SAS-Beispiele
Dieses Thema enthält Beispiele dafür, wie eine SAS mit der REST-API verwendet wird. Mit Shared Access Signatures können Sie Zugriffsrechte für Container und Blobs, Tabellen, Warteschlangen oder Dateien bereitstellen. Wenn Sie eine SAS bereitstellen, können Sie Benutzern über einen angegebenen Zeitraum eingeschränkten Zugriff auf einen bestimmten Container, einen BLOB, eine Warteschlange, eine Tabelle oder einen Tabellenentitätsbereich gewähren. Ausführliche Informationen zum Erstellen, Analysieren und Verwenden von Shared Access Signatures finden Sie unter Delegating Access with a Shared Access Signature (Delegating Access with a Shared Access Signature). Informationen zur Verwendung der .NET-Speicherclientbibliothek zum Erstellen von Shared Access Signatures finden Sie unter Erstellen und Verwenden einer Shared Access Signature.
Beispiele für BLOBs
Die Beispiele in diesem Abschnitt veranschaulichen, wie eine SAS für REST-Vorgänge in BLOBs verwendet wird.
Beispiel: Abrufen eines BLOBs mithilfe der SAS eines Containers
Versionen vor 2013-08-15
Im folgenden Beispiel wird gezeigt, wie eine SAS für den Lesezugriff auf einen Container erstellt wird.
Die Felder für die signierte Signatur, die die URL enthalten, lauten:
signedstart=2009-02-09
signedexpiry=2009-02-10
signedresource=c
signedpermissions=r
signature=dD80ihBh5jfNpymO5Hg1IdiJIEvHcJpCMiCMnN/RnbI=
signedidentifier=YWJjZGVmZw==
signedversion=2012-02-12
Die Signatur wird wie folgt erstellt:
StringToSign = r + \n
2009-02-09 + \n
2009-02-10 + \n
/myaccount/pictures + \n
YWJjZGVmZw== + \n
2012-02-12
HMAC-SHA256(URL.Decode(UTF8.Encode(StringToSign))) = dD80ihBh5jfNpymO5Hg1IdiJIEvHcJpCMiCMnN/RnbI=
Die Anforderungs-URL gibt Leseberechtigungen für den pictures Container für das angegebene Intervall an. Die durch die Anforderungs-URL dargestellte Ressource ist ein Blob, aber die Shared Access Signature wird im Container angegeben. Die SAS kann jedoch auch für das BLOB selbst angegeben werden.
GET https://myaccount.blob.core.windows.net/pictures/profile.jpg?sv=2012-02-12&st=2009-02-09&se=2009-02-10&sr=c&sp=r&si=YWJjZGVmZw%3d%3d&sig=dD80ihBh5jfNpymO5Hg1IdiJIEvHcJpCMiCMnN%2fRnbI%3d
HTTP/1.1
Host: myaccount.blob.core.windows.net
x-ms-date: <date>
Version 2013-08-15 und höher
Im folgenden Beispiel wird veranschaulicht, wie eine SAS für den Lesezugriff auf einen Container erstellt wird, wobei die Speicherdienstversion 2013-08-15 verwendet wird.
Mit Version 2013-08-15 werden neue Abfrageparameter eingeführt, die dem Client die Ausgabe der Anforderung ermöglichen, über die ausschließlich Antwortheader für diese SAS überschrieben werden.
Die Antwortheader und die entsprechenden Abfrageparameter lauten wie folgt:
| Antwortheadername | Entsprechender SAS-Abfrageparameter |
|---|---|
Cache-Control |
rscc |
Content-Disposition |
rscd |
Content-Encoding |
rsce |
Content-Language |
rscl |
Content-Type |
rsct |
Die Felder, die die StringToSign-Zeichenfolge für die Signatur umfassen, sind:
signedstart=2013-08-16
signedexpiry=2013-08-17
signedresource=c
signedpermissions=r
signedidentifier=YWJjZGVmZw==
signedversion=2013-08-15
responsecontent-disposition=file; attachment
responsecontent-type=binary
Die StringToSign-Zeichenfolge wird wie folgt erstellt:
StringToSign = r + \n
2013-08-16 + \n
2013-08-17 + \n
/myaccount/pictures + \n
YWJjZGVmZw== + \n
2013-08-15 + \n
+ \n
file; attachment + \n
+ \n
+ \n
binary
HMAC-SHA256(URL.Decode(UTF8.Encode(StringToSign))) = a39+YozJhGp6miujGymjRpN8tsrQfLo9Z3i8IRyIpnQ=
Über die SAS werden Leseberechtigungen für den pictures-Container angegeben, die für den angegebenen Zeitraum gültig sind. Die durch die Anforderungs-URL dargestellte Ressource ist ein Blob, aber die Shared Access Signature wird im Container angegeben. Die SAS kann jedoch auch für das BLOB selbst angegeben werden.
GET https://myaccount.blob.core.windows.net/pictures/profile.jpg?sv=2013-08-15&st=2013-08-16&se=2013-08-17&sr=c&sp=r&rscd=file;%20attachment&rsct=binary &sig=YWJjZGVmZw%3d%3d&sig=a39%2BYozJhGp6miujGymjRpN8tsrQfLo9Z3i8IRyIpnQ%3d HTTP/1.1
Für einen Client, der eine Anforderung mit dieser Signatur stellt, wird der Vorgang Blob abrufen ausgeführt, wenn die folgenden Kriterien erfüllt sind:
Die Anforderung wurde erfolgreich autorisiert.
Die Anforderung wird innerhalb des Zeitrahmens ausgeführt, der von der SAS angegeben wird.
Durch die Anforderung werden keine Bestimmungen der zugehörigen gespeicherten Zugriffsrichtlinie verletzt.
Das von der Anforderung angegebene BLOB (/myaccount/pictures/profile.jpg) befindet sich in dem Container, der als signierte Ressource (/myaccount/pictures) angegeben ist.
Die Angabe von rsct=binary und rscd=file; attachment für die Shared Access Signature überschreibt die Header für Inhaltstyp und Inhaltsdisposition in der Antwort.
Eine erfolgreiche Antwort auf eine Anforderung, die mithilfe dieser SAS ausgeführt wird, sieht etwa wie folgt aus:
Status Response:
HTTP/1.1 200 OK
Response Headers:
x-ms-blob-type: BlockBlob
Content-Length: 11
Content-Type: binary
Content-Disposition: file; attachment
ETag: "0x8CB171DBEAD6A6B"
x-ms-version: 2013-08-15
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0
Beispiel: Hochladen eines Blobs mithilfe der Shared Access Signature eines Containers
Im folgenden Beispiel wird veranschaulicht, wie Sie eine SAS zum Schreiben eines BLOBs erstellen. In diesem Beispiel erstellen Sie eine Signatur, die Schreibberechtigungen für alle BLOBs im Container gewährt. Anschließend wird die SAS verwendet, um ein BLOB in den Container zu schreiben.
Zu den signierten Feldern, aus denen die URL besteht, gehören:
signedstart=2015-07-01T08:49Z
signedexpiry=2015-07-02T08:49Z
signedresource=c
signedpermissions=w
signedidentifier=YWJjZGVmZw==
signedversion=2015-02-21
Die Signatur wird wie folgt erstellt:
StringToSign = w + \n
2015-07-01T08:49Z + \n
2015-07-02T08:49Z + \n
/myaccount/pictures + \n
YWJjZGVmZw== + \n
2013-08-15
HMAC-SHA256(URL.Decode(UTF8.Encode(StringToSign))) = Rcp6gQRfV7WDlURdVTqCa+qEArnfJxDgE+KH3TCChIs=
Die Anforderungs-URL gibt Schreibberechtigungen für den pictures Container für das angegebene Intervall an. Die durch die Anforderungs-URL dargestellte Ressource ist ein Blob, aber die Shared Access Signature wird im Container angegeben. Die SAS kann jedoch auch für das BLOB selbst angegeben werden.
PUT https://myaccount.blob.core.windows.net/pictures/photo.jpg?sv=2015-02-21&st=2015-07-01T08%3a49Z&se=2015-07-02T08%3a49Z&
sr=c&sp=w&si=YWJjZGVmZw%3d%3d&sig=Rcp6gQRfV7WDlURdVTqCa%2bqEArnfJxDgE%2bKH3TCChIs%3d HTTP/1.1
Host: myaccount.blob.core.windows.net
Content-Length: 12
Hello World.
Mit dieser Signatur wird Put Blob aufgerufen, wenn die folgenden Kriterien erfüllt sind:
Die Anforderung wurde erfolgreich autorisiert.
Die Anforderung wird innerhalb des Zeitrahmens ausgeführt, der von der SAS angegeben wird.
Durch die Anforderung werden keine Bestimmungen der zugehörigen gespeicherten Zugriffsrichtlinie verletzt.
Das von der Anforderung (/myaccount/pictures/photo.jpg) angegebene BLOB befindet sich in dem Container, der als signierte Ressource (/myaccount/pictures) angegeben wurde.
Beispiel: Löschen eines BLOBs mithilfe der SAS eines BLOBs
Im folgenden Beispiel wird die Erstellung einer SAS veranschaulicht, die Löschberechtigungen für ein BLOB erteilt und ein BLOB löscht.
Achtung
Beachten Sie, dass eine SAS für einen DELETE-Vorgang mit Umsicht verteilt werden sollte, da die Folgen unübersehbar sind, wenn Sie einem Client das Löschen von Daten erlauben.
Die Felder für die signierte Signatur, die die URL enthalten, lauten:
signedstart=2015-07-01T08:49:37.0000000Z
signedexpiry=2015-07-02T08:49:37.0000000Z
signedresource=b
signedpermissions=d
signature=+SzBm0wi8xECuGkKw97wnkSZ/62sxU+6Hq6a7qojIVE=
signedidentifier=YWJjZGVmZw==
signedversion=2015-02-21
Die Signatur wird wie folgt erstellt:
StringToSign = d + \n
2015-07-01T08:49:37.0000000Z + \n
2015-07-02T08:49:37.0000000Z + \n
blob/myaccount/pictures/profile.jpg + \n
YWJjZGVmZw==
2015-02-21
HMAC-SHA256(URL.Decode(UTF8.Encode(StringToSign))) = +SzBm0wi8xECuGkKw97wnkSZ/62sxU+6Hq6a7qojIVE=
In der Anforderungs-URL werden Löschberechtigungen für den pictures-Container festgelegt, die für den angegebenen Zeitraum gültig sind. Die durch die Anforderungs-URL dargestellte Ressource ist ein Blob, und die Shared Access Signature wird in diesem Blob angegeben. Sie können die SAS auch für den Container des BLOBs angeben, um eine Löschberechtigung für beliebige BLOBs im Container zu gewähren.
DELETE https://myaccount.blob.core.windows.net/pictures/profile.jpg?sv=2015-02-21&st=2015-07-01T08%3a49%3a37.0000000Z&se=2015-07-02T08%3a49%3a37.0000000Z&sr=b&sp=d&si=YWJjZGVmZw%3d%3d&sig=%2bSzBm0wi8xECuGkKw97wnkSZ%2f62sxU%2b6Hq6a7qojIVE%3d HTTP/1.1
Host: myaccount.blob.core.windows.net
Content-Length: 0
Mit dieser Signatur wird Delete Blob aufgerufen, wenn die folgenden Kriterien erfüllt sind:
Die Anforderung wurde erfolgreich autorisiert.
Die Anforderung wird innerhalb des Zeitrahmens ausgeführt, der von der SAS angegeben wird.
Durch die Anforderung werden keine Bestimmungen der zugehörigen gespeicherten Zugriffsrichtlinie verletzt.
Das in der Anforderung (/myaccount/pictures/profile.jpg) angegebene BLOB entspricht dem BLOB, das als signierte Ressource angegeben wurde.
Dateibeispiele
Dieser Abschnitt enthält Beispiele, die Shared Access Signatures für REST-Vorgänge für Dateien veranschaulichen.
Beispiel: Abrufen einer Datei mithilfe der Shared Access Signature einer Freigabe
Das folgende Beispiel zeigt, wie Sie eine Shared Access Signature für den Lesezugriff auf eine Freigabe erstellen.
Wenige Abfrageparameter können es dem Client, der die Anforderung ausgibt, ermöglichen, Antwortheader für diese Shared Access Signature außer Kraft zu setzen.
Die Antwortheader und die entsprechenden Abfrageparameter lauten wie folgt:
| Antwortheadername | Entsprechender SAS-Abfrageparameter |
|---|---|
Cache-Control |
rscc |
Content-Disposition |
rscd |
Content-Encoding |
rsce |
Content-Language |
rscl |
Content-Type |
rsct |
Die Felder, die die StringToSign-Zeichenfolge für die Signatur umfassen, sind:
signedstart=2015-07-01T08:49Z
signedexpiry=2015-07-02T08:49Z
signedresource=c
signedpermissions=r
signature=dD80ihBh5jfNpymO5Hg1IdiJIEvHcJpCMiCMnN/RnbI=
signedidentifier=YWJjZGVmZw==
signedversion=2015—02-21
responsecontent-disposition=file; attachment
responsecontent-type=binary
Die StringToSign-Zeichenfolge wird wie folgt erstellt:
StringToSign = r + \n
2015-07-01T08:49Z + \n
2015-07-02T08:49Z + \n
file/myaccount/pictures + \n
YWJjZGVmZw== + \n
2015—02-21 + \n
+ \n
file; attachment + \n
+ \n
+ \n
binary
HMAC-SHA256(URL.Decode(UTF8.Encode(StringToSign))) = a39+YozJhGp6miujGymjRpN8tsrQfLo9Z3i8IRyIpnQ=
Die Shared Access Signature gibt Leseberechtigungen für die pictures Freigabe für das angegebene Intervall an. Die durch die Anforderungs-URL dargestellte Ressource ist eine Datei, aber die Shared Access Signature wird auf der Freigabe angegeben. Es ist auch möglich, sie für die Datei selbst anzugeben.
GET https://myaccount.file.core.windows.net/pictures/profile.jpg?sv=2015-02-21&st=2015-07-01T08:49Z&se=2015-07-02T08:49Z&sr=c&sp=r&rscd=file;%20attachment&rsct=binary&sig=YWJjZGVmZw%3d%3d&sig=a39%2BYozJhGp6miujGymjRpN8tsrQfLo9Z3i8IRyIpnQ%3d
Für einen Client, der eine Anforderung mit dieser Signatur stellt, wird der Vorgang Datei abrufen ausgeführt, wenn die folgenden Kriterien erfüllt sind:
Die Anforderung wurde erfolgreich autorisiert.
Die Anforderung wird innerhalb des Zeitrahmens ausgeführt, der von der SAS angegeben wird.
Durch die Anforderung werden keine Bestimmungen der zugehörigen gespeicherten Zugriffsrichtlinie verletzt.
Die durch die Anforderung angegebene Datei (/myaccount/pictures/profile.jpg) befindet sich in der Freigabe, die als signierte Ressource (/myaccount/pictures) angegeben ist.
Durch die Angabe von rsct=binary und rscd=file; attachment für die Shared Access Signature werden die content-type Header und content-disposition in der Antwort überschrieben.
Eine erfolgreiche Antwort auf eine Anforderung, die mithilfe dieser SAS ausgeführt wird, sieht etwa wie folgt aus:
Status Response:
HTTP/1.1 200 OK
Response Headers:
Content-Length: 11
Content-Type: binary
Content-Disposition: file; attachment
ETag: "0x8CB171DBEAD6A6B"
x-ms-version: 2015-02-21
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0
Beispiel: Hochladen einer Datei mithilfe einer Shared Access Signature auf einer Freigabe
Das folgende Beispiel zeigt, wie Sie eine Shared Access Signature zum Schreiben einer Datei erstellen. In diesem Beispiel erstellen wir eine Signatur, die Schreibberechtigungen für alle Dateien in der Freigabe erteilt. Anschließend verwenden wir die Shared Access Signature, um in eine Datei in der Freigabe zu schreiben.
Die Felder für die signierte Signatur, die die URL enthalten, lauten:
signedstart=2015-07-01T08:49Z
signedexpiry=2015-07-02T08:49Z
signedresource=c
signedpermissions=w
signature=Rcp6gQRfV7WDlURdVTqCa+qEArnfJxDgE+KH3TCChIs=
signedidentifier=YWJjZGVmZw==
signedversion=2015-02-21
Die Signatur wird wie folgt erstellt:
StringToSign = w + \n
2015-07-01T08:49Z + \n
2015-07-02T08:49Z + \n
file/myaccount/pictures + \n
YWJjZGVmZw== + \n
2015-02-21
HMAC-SHA256(URL.Decode(UTF8.Encode(StringToSign))) = Rcp6gQRfV7WDlURdVTqCa+qEArnfJxDgE+KH3TCChIs=
Die Anforderungs-URL gibt Schreibberechtigungen für den pictures Container für das angegebene Intervall an. Die durch die Anforderungs-URL dargestellte Ressource ist ein Blob, aber die Shared Access Signature wird im Container angegeben. Die SAS kann jedoch auch für das BLOB selbst angegeben werden.
PUT https://myaccount.file.core.windows.net/pictures/photo.jpg?sv=2015-02-21&st=2015-07-01T08%3a49Z&se=2015-07-01T08%3a49Z&
sr=c&sp=w&si=YWJjZGVmZw%3d%3d&sig=Rcp6gQRfV7WDlURdVTqCa%2bqEArnfJxDgE%2bKH3TCChIs%3d HTTP/1.1
Host: myaccount.blob.core.windows.net
Content-Length: 12
Hello World.
Mit dieser Signatur wird Create File aufgerufen, wenn die folgenden Kriterien erfüllt sind:
Die Anforderung wurde erfolgreich autorisiert.
Die Anforderung wird innerhalb des Zeitrahmens ausgeführt, der von der SAS angegeben wird.
Durch die Anforderung werden keine Bestimmungen der zugehörigen gespeicherten Zugriffsrichtlinie verletzt.
Die von der Anforderung angegebene Datei (/myaccount/pictures/photo.jpg) befindet sich in der Freigabe, die als signierte Ressource angegeben ist (/myaccount/pictures).
Beispiel: Löschen einer Datei mithilfe der Shared Access Signature einer Datei
Das folgende Beispiel zeigt, wie Sie eine Freigegebene Zugriffssignatur erstellen, die Löschberechtigungen für eine Datei erteilt, und anschließend die Freigegebene Zugriffssignatur zum Löschen der Datei verwendet.
Achtung
Eine freigegebene Zugriffssignatur für einen DELETE-Vorgang sollte vernünftig verteilt werden, da das Löschen von Daten durch einen Client unbeabsichtigte Folgen haben kann.
Die Felder für die signierte Signatur, die die URL enthalten, lauten:
signedstart=2015-07-01T08:49:37.0000000Z
signedexpiry=2015-07-02T08:49:37.0000000Z
signedresource=b
signedpermissions=d
signature=+SzBm0wi8xECuGkKw97wnkSZ/62sxU+6Hq6a7qojIVE=
signedidentifier=YWJjZGVmZw==
signedversion=2015-02-21
Die Signatur wird wie folgt erstellt:
StringToSign = d + \n
2015-07-01T08:49:37.0000000Z + \n
2015-07-02T08:49:37.0000000Z + \n
file/myaccount/pictures/profile.jpg + \n
YWJjZGVmZw==
2015-02-21
HMAC-SHA256(URL.Decode(UTF8.Encode(StringToSign))) = +SzBm0wi8xECuGkKw97wnkSZ/62sxU+6Hq6a7qojIVE=
Die Anforderungs-URL gibt Löschberechtigungen für die Bildfreigabe für das angegebene Intervall an. Die durch die Anforderungs-URL dargestellte Ressource ist eine Datei, und die freigegebene Zugriffssignatur wird für diese Datei angegeben. Es ist auch möglich, sie auf der Dateifreigabe anzugeben, um die Berechtigung zum Löschen jeder Datei in der Freigabe zu erteilen.
DELETE https://myaccount.file.core.windows.net/pictures/profile.jpg?sv=2015-02-21&st=2015-07-01T08%3a49%3a37.0000000Z&se=2015-07-02T08%3a49%3a37.0000000Z&sr=b&sp=d&si=YWJjZGVmZw%3d%3d&sig=%2bSzBm0wi8xECuGkKw97wnkSZ%2f62sxU%2b6Hq6a7qojIVE%3d HTTP/1.1
Host: myaccount.blob.core.windows.net
Content-Length: 0
Mit dieser Signatur wird Datei löschen aufgerufen, wenn die folgenden Kriterien erfüllt sind:
Die Anforderung wurde erfolgreich autorisiert.
Die Anforderung wird innerhalb des Zeitrahmens ausgeführt, der von der SAS angegeben wird.
Durch die Anforderung werden keine Bestimmungen der zugehörigen gespeicherten Zugriffsrichtlinie verletzt.
Die durch die Anforderung angegebene Datei (/myaccount/pictures/profile.jpg) entspricht der datei, die als signierte Ressource angegeben ist.
Beispiele für Warteschlangen
Die Beispiele in diesem Abschnitt veranschaulichen, wie eine SAS für REST-Vorgänge in Warteschlangen verwendet wird. In diesen Beispielen wird der Warteschlangendienstvorgang nur ausgeführt, wenn die folgenden Bedingungen erfüllt sind:
Die Anforderung wurde erfolgreich autorisiert.
Die Anforderung wird innerhalb des Zeitrahmens ausgeführt, der von der SAS angegeben wird.
Durch die Anforderung werden keine Bestimmungen der zugehörigen gespeicherten Zugriffsrichtlinie verletzt.
Die von der Anforderung angegebene Warteschlange entspricht derselben Warteschlange, die von der SAS autorisiert wurde.
Beispiel: Abrufen von Nachrichten mithilfe einer SAS
Im folgenden Beispiel wird veranschaulicht, wie eine SAS zum Abrufen von Nachrichten aus einer Warteschlange erstellt wird. Durch diese Signatur werden der Warteschlange Berechtigungen zur Nachrichtenverarbeitung gewährt. Schließlich wird die SAS in diesem Beispiel dazu verwendet, eine Nachricht aus der Warteschlange abzurufen.
Untersuchen Sie die folgenden Signierten Signaturfelder, die Konstruktion der Zeichenfolgen-zu-Sign und die Erstellung der URL, die den Vorgang Nachrichten abrufen aufruft, nachdem die Anforderung autorisiert wurde:
signedstart=2015-07-01T08:49Z
signedexpiry=2015-07-02T08:49Z
signedpermissions=p
signature=+SzBm0wi8xECuGkKw97wnkSZ/62sxU+6Hq6a7qojIVE=
signedidentifier=YWJjZGVmZw==
signedversion=2015-02-21
StringToSign = p + \n
2015-07-01T08:49Z + \n
2015-07-02T08:49Z + \n
queue/myaccount/myqueue + \n
YWJjZGVmZw== + \n
2015-02-21
GET https://myaccount.queue.core.windows.net/myqueue/messages?visibilitytimeout=120&sv=2015-02-21&st=2015-07-01T08%3a49Z&se=2015-07-02T08%3a49Z&sp=p&si=YWJjZGVmZw%3d%3d&sig=jDrr6cna7JPwIaxWfdH0tT5v9dc%3d HTTP/1.1
Host: myaccount.queue.core.windows.net
Beispiel: Hinzufügen einer Nachricht mithilfe einer SAS
Im folgenden Beispiel wird veranschaulicht, wie eine SAS zum Hinzufügen einer Nachricht zu einer Warteschlange erstellt wird. Durch diese Signatur werden Hinzufügeberechtigungen für die Warteschlange gewährt. Schließlich wird die Signatur in diesem Beispiel zum Hinzufügen einer Nachricht verwendet.
Untersuchen Sie die folgenden signierten Signaturfelder, die Konstruktion der StringToSign-Zeichenfolge und die Konstruktion der URL, die den Vorgang Put Message aufruft, nachdem die Anforderung autorisiert wurde:
signedstart=2015-07-01T08:49Z
signedexpiry=2015-07-02T08:49Z
signedpermissions=a
signature= +SzBm0wi8xECuGkKw97wnkSZ/62sxU+6Hq6a7qojIVE=
signedidentifier=YWJjZGVmZw==
signedversion=2015-02-21
StringToSign = a + \n
2015-07-01T08:49Z + \n
2015-07-02T08:49Z + \n
queue/myaccount/myqueue + \n
YWJjZGVmZw== + \n
2015-02-21
POST https://myaccount.queue.core.windows.net/myqueue/messages?visibilitytimeout=120&sv=2015-02-21&st=2015-07-01T08%3a49Z&se=2015-07-02T08%3a49Z&sp=a&si=YWJjZGVmZw%3d%3d&sig=jDrr6cna7JPwIaxWfdH0tT5v9dc%3d HTTP/1.1
Host: myaccount.queue.core.windows.net
Content-Length: 100
<QueueMessage>
<MessageText>PHNhbXBsZT5zYW1wbGUgbWVzc2FnZTwvc2FtcGxlPg==</MessageText>
</QueueMessage>
Beispiel: Überprüfung auf vorliegende Nachrichten und Abrufen einer Nachricht mithilfe einer SAS
Im folgenden Beispiel wird veranschaulicht, wie eine SAS erstellt wird, um die Warteschlange auf vorliegende Nachrichten zu überprüfen sowie die Nachrichtenanzahl der Warteschlange abzurufen. Durch diese Signatur werden Leseberechtigungen für die Warteschlange erteilt. Schließlich wird die SAS in diesem Beispiel verwendet, um eine Überprüfung auf vorliegende Nachrichten durchzuführen und dann die Metadaten der Warteschlange zu lesen, in denen auch die Nachrichtenanzahl enthalten ist.
Untersuchen Sie die folgenden Signierten Signaturfelder, die Konstruktion der Zeichenfolgen-zu-Vorzeichen und die Konstruktion der URL, die die Vorgänge Peek Messages und Get Queue Metadata aufruft:
signedstart=2015-07-01T08:49Z
signedexpiry=2015-07-02T08:49Z
signedpermissions=r
signature=+SzBm0wi8xECuGkKw97wnkSZ/62sxU+6Hq6a7qojIVE=
signedidentifier=YWJjZGVmZw==
signedversion=2015-02-21
StringToSign = r + \n
2015-07-01T08:49Z + \n
2015-07-02T08:49Z + \n
queue/myacccount/myqueue + \n
YWJjZGVmZw== + \n
2015-02-21
GET https://myaccount.queue.core.windows.net/myqueue/messages?peekonly=true&sv=2015-02-21&st=2015-07-01T08%3a49Z&se=2015-07-02T08%3a49Z&sp=r&si=YWJjZGVmZw%3d%3d&sig=jDrr6cna7JPwIaxWfdH0tT5v9dc%3d HTTP/1.1
Host: myaccount.queue.core.windows.net
GET https://myaccount.queue.core.windows.net/myqueue?comp=metadata&sv=2015-02-21&st=2015-07-01T08%3a49Z&se=2015-07-01T08%3a49Z&sp=r&si=YWJjZGVmZw%3d%3d&sig=jDrr6cna7JPwIaxWfdH0tT5v9dc%3d HTTP/1.1
Host: myaccount.queue.core.windows.net
Beispiele für Tabellen
Die Beispiele in diesem Abschnitt veranschaulichen, wie eine SAS für REST-Vorgänge in Tabellen verwendet wird. In diesen Beispielen wird der Tabellendienstvorgang nur ausgeführt, wenn die folgenden Bedingungen erfüllt sind:
Die Anforderung wurde erfolgreich autorisiert.
Die Anforderung wird innerhalb des Zeitrahmens ausgeführt, der von der SAS angegeben wird.
Durch die Anforderung werden keine Bestimmungen der zugehörigen gespeicherten Zugriffsrichtlinie verletzt.
Die von der Anforderung angegebene Warteschlange entspricht derselben Warteschlange, die von der SAS autorisiert wurde.
Beispiel: Abfragen einer Tabelle mithilfe einer SAS
Im folgenden Beispiel wird veranschaulicht, wie eine SAS für die Abfrage von Entitäten in einer Tabelle erstellt wird. Durch die Signatur werden Abfrageberechtigungen für einen bestimmten Tabellenbereich gewährt. Schließlich wird die SAS in diesem Beispiel verwendet, um Entitäten innerhalb des Bereichs abzufragen.
Überprüfen Sie die folgenden Felder für signierte Signaturen, das Format der StringToSign-Zeichenfolge und das Format der URL, durch die der Vorgang zum Abfragen von Entitäten aufgerufen wird. Die Ergebnisse des Vorgangs zum Abfragen von Entitäten umfassen nur die Entitäten in dem Bereich, der von startpk, startrk, endpk und endrk definiert wird.
signedstart=2015-07-01T08:49Z
signedexpiry=2015-07-02T08:49Z
signedpermissions=r
signature= +SzBm0wi8xECuGkKw97wnkSZ/62sxU+6Hq6a7qojIVE=
signedidentifier=YWJjZGVmZw==
signedversion=2015-02-21
startpk="Coho Winery"
startrk="Auburn"
endpk="Coho Winery"
endrk="Seattle"
String-To-Sign = r + \n
2015-07-01T08:49Z + \n
2015-07-02T08:49Z + \n
table/myaccount/mytable + \n
YWJjZGVmZw== + \n
2015-02-21 + \n
Coho Winery + \n
Auburn + \n
Coho Winery + \n
Seattle
GET https://myaccount.table.core.windows.net/MyTable?$filter=PartitionKey%20eq%20'Coho%20Winery'&sv=2015-02-21&tn=MyTable&st=2015-07-01T08%3a49Z&se=2015-07-02T08%3a49Z&sp=r&si=YWJjZGVmZw%3d%3d&sig=jDrr6cna7JPwIaxWfdH0tT5v9dc%3d&spk=Coho%20Winery&srk=Auburn&epk=Coho%20Winery&erk=Seattle HTTP/1.1
Host: myaccount.table.core.windows.net
DataServiceVersion: 3.0;NetFx
MaxDataServiceVersion: 3.0;NetFx
Beispiel: Aktualisieren einer Tabelle mithilfe einer SAS
Im folgenden Beispiel wird veranschaulicht, wie eine SAS zum Aktualisieren von Entitäten in einer Tabelle erstellt wird. Durch die Signatur werden Updateberechtigungen für einen bestimmten Entitätenbereich gewährt. Schließlich wird die SAS in diesem Beispiel verwendet, um eine Entität im Bereich zu aktualisieren.
Überprüfen Sie die folgenden Felder für signierte Signaturen, das Format der StringToSign-Zeichenfolge und das Format der URL, durch die der Vorgang zum Aktualisieren von Entitäten aufgerufen wird. Durch den Vorgang zum Aktualisieren von Entitäten können nur Entitäten innerhalb des Partitionsbereichs aktualisiert werden, der von startpk und endpk definiert wird.
signedstart=2015-07-01T08:49Z
signedexpiry=2015-07-02T08:49Z
signedpermissions=u
signature= +SzBm0wi8xECuGkKw97wnkSZ/62sxU+6Hq6a7qojIVE=
signedidentifier=YWJjZGVmZw==
signedversion=2015-02-21
startpk="Coho Winery"
endpk="Coho Winery"
String-To-Sign = u + \n
2015-07-01T08:49Z + \n
2015-07-02T08:49Z + \n
table/myaccount/mytable + \n
YWJjZGVmZw== + \n
2015-02-21 + \n
Coho Winery + \n
+ \n
Coho Winery + \n
MERGE https://myaccount.table.core.windows.net/MyTable(PartitionKey='Coho%20Winery',RowKey='Seattle')?sv=2015-02-21&tn=MyTable&st=2015-07-01T08%3a49Z&se=2015-07-02T08%3a49Z&sp=u&si=YWJjZGVmZw%3d%3d&sig=jDrr6cna7JPwIaxWfdH0tT5v9dc%3d&spk=Coho%20Winery&epk=Coho%20Winery HTTP/1.1
Host: myaccount.table.core.windows.net
DataServiceVersion: 3.0;NetFx
MaxDataServiceVersion: 3.0;NetFx
If-Match: *
Content-Type: application/atom+xml
Content-Length: 696
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<entry xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices" xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata" xmlns="http://www.w3.org/2005/Atom">
<title />
<author>
<name />
</author>
<id>https://myaccount.table.core.windows.net/MyTable(PartitionKey='Coho Winery',RowKey='Seattle')</id>
<content type="application/xml">
<m:properties>
<d:PartitionKey>P</d:PartitionKey>
<d:RowKey>R</d:RowKey>
<d:Timestamp m:type="Edm.DateTime">0001-01-01T00:00:00</d:Timestamp>
</m:properties>
</content>
</entry>
Weitere Informationen
Delegieren des Zugriffs mit einer Shared Access Signature
Erstellen einer Dienst-SAS