(0) exportieren Drucken
Alle erweitern

Set Queue ACL

Letzte Aktualisierung: August 2013

Der Set Queue ACL-Vorgang legt gespeicherte Zugriffsrichtlinien für die Warteschlange fest, die mit SAS (Shared Access Signature) verwendet werden können. Weitere Informationen finden Sie unter Festlegen einer gespeicherten Zugriffsrichtlinie (REST-API).

noteHinweis
Der Set Queue ACL-Vorgang ist in Version 2012-02-12 und höher verfügbar.

Die Set Queue ACL-Anforderung kann wie folgt erstellt werden. HTTPS wird empfohlen. Ersetzen Sie myaccount durch den Namen Ihres Speicherkontos:

 

Methode Anforderungs-URI HTTP-Version

PUT

https://myaccount.queue.core.windows.net/myqueue?comp=acl

HTTP/1.1

Wenn Sie eine Anforderung für den emulierten Speicherdienst ausführen, geben Sie den Emulatorhostnamen und den Port des Warteschlangendiensts mit 127.0.0.1:10001 an, gefolgt vom Namen des emulierten Speicherkontos:

 

Methode Anforderungs-URI HTTP-Version

PUT

http://127.0.0.1:10001/devstoreaccount1/myqueue?comp=acl

HTTP/1.1

Weitere Informationen finden Sie unter About Development Storage und Unterschiede zwischen dem Speicheremulator und den Azure-Speicherdiensten.

Im Anforderungs-URI können die folgenden zusätzlichen Parameter angegeben werden.

 

Parameter Beschreibung

timeout

Optional. Der timeout-Parameter wird in Sekunden angegeben. Weitere Informationen finden Sie unter Festlegen von Timeouts für Vorgänge des Warteschlangendiensts.

In der folgenden Tabelle werden erforderliche und optionale Anforderungsheader beschrieben.

 

Anforderungsheader Beschreibung

Authorization

Erforderlich. Gibt das Authentifizierungsschema, den Kontonamen und die Signatur an. Weitere Informationen finden Sie unter Authentifizierung für die Azure-Speicherdienste.

Date - oder - x-ms-date

Erforderlich. Gibt die Uhrzeit der Anforderung in koordinierter Weltzeit (UTC) an. Weitere Informationen finden Sie unter Authentifizierung für die Azure-Speicherdienste.

x-ms-version

Optional. Gibt die Version des für die Anforderung zu verwendenden Vorgangs an. Weitere Informationen finden Sie unter Versionsverwaltung für die Azure-Speicherdienste.

x-ms-client-request-id

Optional. Stellt einen vom Client generierten, nicht transparenten Wert mit einer Zeichenbeschränkung von 1 KB bereit, der in den Analyseprotokollen erfasst wird, wenn die Protokollierung der Speicheranalyse aktiviert ist. Die Verwendung dieses Headers wird dringend empfohlen, um clientseitige Aktivitäten mit den vom Server empfangenen Anforderungen zu korrelieren. Weitere Informationen finden Sie unter Informationen zur Protokollierung durch die Speicheranalyse und Windows Azure-Protokollierung: Verwenden von Protokollen zur Nachverfolgung von Speicheranforderungen.

Sie geben eine gespeicherte Zugriffsrichtlinie an, indem Sie im Anforderungstext für den Set Queue ACL-Vorgang einen eindeutigen Bezeichner und eine Zugriffsrichtlinie bereitstellen.

Das SignedIdentifier-Element enthält den eindeutigen Bezeichner, der im Id-Element angegeben ist, und die Details der Zugriffsrichtlinie, die im AccessPolicy-Element angegeben sind. Die maximale Länge des eindeutigen Bezeichners beträgt 64 Zeichen.

Das Start-Feld und das Expiry-Feld müssen als UTC-Zeit ausgedrückt werden und einem gültigen ISO 8061-Format entsprechen. Folgende ISO 8061-Formate werden unterstützt:

  • YYYY-MM-DD

  • YYYY-MM-DDThh:mmTZD

  • YYYY-MM-DDThh:mm:ssTZD

  • YYYY-MM-DDThh:mm:ss.ffffffTZD

Im Datumsteil dieser Formate ist YYYY die vierstellige Darstellung des Jahrs, MM die zweistellige Darstellung des Monats und DD die zweistellige Darstellung des Tags. Im Uhrzeitteil ist hh die Darstellung der Stunden in 24-Stunden-Notation, mm die zweistellige Darstellung der Minuten, ss die zweistellige Darstellung der Sekunden und ffffff die sechsstellige Darstellung der Millisekunden. Der Zeitkennzeichner T trennt den Datums- und Uhrzeitteil der Zeichenfolge, und der Zeitzonenkennzeichner TZD gibt die Zeitzone an.

<?xml version="1.0" encoding="utf-8"?>
<SignedIdentifiers>
  <SignedIdentifier> 
    <Id>unique-64-character-value</Id>
    <AccessPolicy>
      <Start>start-time</Start>
      <Expiry>expiry-time</Expiry>
      <Permission>abbreviated-permission-list</Permission>
    </AccessPolicy>
  </SignedIdentifier>
</SignedIdentifiers>

Request Syntax:
PUT https://myaccount.queue.core.windows.net/myqueue?comp=acl HTTP/1.1
Request Headers:
x-ms-version: 2012-02-12
x-ms-date: Sun, 25 Sep 2011 00:42:49 GMT
Authorization: SharedKey myaccount:V47F2tYLS29MmHPhiR8FyiCny9zO5De3kVSF0RYQHmo=
Request Body:
<?xml version="1.0" encoding="utf-8"?>
<SignedIdentifiers>
  <SignedIdentifier> 
    <Id>MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=</Id>
    <AccessPolicy>
      <Start>2009-09-28T08:49:37.0000000Z</Start>
      <Expiry>2009-09-29T08:49:37.0000000Z</Expiry>
      <Permission>raup</Permission>
    </AccessPolicy>
  </SignedIdentifier>
</SignedIdentifiers>

Die Antwort enthält den HTTP-Statuscode und einen Satz von Antwortheadern.

Bei einem erfolgreichen Vorgang wird der Statuscode 204 (Kein Inhalt) zurückgegeben.

Weitere Informationen zu Statuscodes finden Sie unter Status- und Fehlercodes.

Die Antwort für diesen Vorgang umfasst die folgenden Header. Die Antwort kann außerdem weitere HTTP-Standardheader enthalten. Alle Standardheader entsprechen der HTTP/1.1-Protokollspezifikation.

 

Antwortheader Beschreibung

x-ms-request-id

Dieser Header identifiziert die erfolgte Anforderung eindeutig und kann für die Problembehandlung der Anforderung verwendet werden. Weitere Informationen finden Sie unter Problembehandlung für API-Vorgänge.

x-ms-version

Gibt die Version des Warteschlangendiensts an, der zum Ausführen der Abfrage verwendet wird. Dieser Header wird für Anforderungen zurückgegeben, die für Version 2009-09-19 und höher erfolgen.

Date

Ein vom Dienst generierter Datums-/Uhrzeitwert in UTC, der angibt, wann die Antwort initiiert wurde.

Response Status:
HTTP/1.1 204 No Content
Response Headers:
Transfer-Encoding: chunked
Date: Sun, 25 Sep 2011 22:42:55 GMT
x-ms-version: 2012-02-12
Server: Windows-Azure-Queue/1.0 Microsoft-HTTPAPI/2.0

Dieser Vorgang kann nur vom Kontobesitzer aufgerufen werden.

Nur der Kontobesitzer kann auf Ressourcen in einer bestimmten Warteschlange zugreifen, es sei denn, der Besitzer hat eine SAS für eine Ressource in der Warteschlange ausgegeben.

Wenn Sie Berechtigungen für eine Warteschlange festlegen, werden die vorhandenen Berechtigungen ersetzt. Um die Berechtigungen der Warteschlange zu aktualisieren, rufen Sie Abrufen einer Warteschlangen-ACL auf, um alle der Warteschlange zugeordneten Zugriffsrichtlinien abzurufen, ändern Sie die gewünschte Zugriffsrichtlinie, und rufen Sie anschließend Set Queue ACL mit dem vollständigen Satz von Daten auf, um das Update durchzuführen.

Festlegen von gespeicherten Zugriffsrichtlinien

Eine gespeicherte Zugriffsrichtlinie kann die Startzeit, die Ablaufzeit und die Berechtigungen für die SAS angeben, denen sie zugeordnet ist. Je nachdem, wie Sie den Zugriff auf die Warteschlangenressource steuern möchten, können Sie alle diese Parameter in der gespeicherten Zugriffsrichtlinie angeben und sie in der URL für die SAS auslassen. Auf diese Weise können Sie das Verhalten der zugeordneten Signatur jederzeit ändern sowie aufheben. Oder Sie können einen oder mehrere der Zugriffsrichtlinienparameter in der gespeicherten Zugriffsrichtlinie und die anderen Zugriffsrichtlinienparameter in der URL angeben. Schließlich können Sie alle Parameter in der URL angeben. In diesem Fall können Sie die gespeicherte Zugriffsrichtlinie verwenden, um die Signatur aufzuheben, aber nicht um ihr Verhalten zu ändern. Weitere Informationen zum Festlegen von Zugriffsrichtlinien finden Sie unter Verwenden einer gespeicherten Zugriffsrichtlinie.

Die SAS und die gespeicherte Zugriffsrichtlinie müssen zusammen alle Felder enthalten, die zum Authentifizieren der Signatur erforderlich sind. Wenn eines der Pflichtfelder fehlt, schlägt die Anforderung fehl. Wenn ein Feld sowohl in der SAS-URL als auch in der gespeicherten Zugriffsrichtlinie angegeben ist, schlägt die Anforderung mit dem Statuscode 400 (Ungültige Anforderung) fehl. Weitere Informationen zu den Feldern, aus denen eine SAS besteht, finden Sie unter Creating a Shared Access Signature.

Beachten Sie, dass für eine Warteschlange höchstens fünf verschiedene Zugriffsrichtlinien gleichzeitig festgelegt sein können. Wenn im Anforderungstext mehr als fünf Zugriffsrichtlinien übergeben werden, gibt der Dienst den Statuscode 400 (Ungültige Anforderung) zurück.

noteHinweis
Wenn Sie eine gespeicherte Zugriffsrichtlinie für eine Warteschlange einrichten, kann es bis zu 30 Sekunden dauern, bis die Richtlinie angewendet wird. Während dieses Intervalls schlägt eine SAS, die der gespeicherten Zugriffsrichtlinie zugeordnet ist, mit dem Statuscode 403 (Unzulässig) so lange fehl, bis die Zugriffsrichtlinie aktiv ist.

Anzeigen:
© 2014 Microsoft