Set Queue ACL

Artikel
06/27/2023

Der Set Queue ACL Vorgang legt gespeicherte Zugriffsrichtlinien für die Warteschlange fest, die mit einer SAS (Shared Access Signature) verwendet werden kann. Weitere Informationen finden Sie unter Definieren einer gespeicherten Zugriffsrichtlinie.

Hinweis

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

Anforderung

Sie können die Set Queue ACL Anforderung wie folgt erstellen. Es wird empfohlen, HTTPS zu verwenden. 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

Emulierte Speicherdienstanforderung

Wenn Sie eine Anforderung für den emulierten Speicherdienst stellen, geben Sie den Hostnamen des Emulators und den Warteschlangendienstport als 127.0.0.1:10001an, 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 Verwenden des Azurite-Emulators für lokale Azure Storage-Entwicklung.

URI-Parameter

Sie können im Anforderungs-URI die folgenden zusätzlichen Parameter angeben:

Parameter	BESCHREIBUNG
`timeout`	Optional. Der `timeout`-Parameter wird in Sekunden angegeben. Weitere Informationen finden Sie unter Festlegen von Timeouts für Warteschlangendienstvorgänge.

Anforderungsheader

Die erforderlichen und optionalen Anforderungsheader werden in der folgenden Tabelle beschrieben:

Anforderungsheader	BESCHREIBUNG
`Authorization`	Erforderlich. Gibt das Autorisierungsschema, den Kontonamen und die Signatur an. Weitere Informationen finden Sie unter Autorisieren von Anforderungen an Azure Storage.
`Date` oder `x-ms-date`	Erforderlich. Gibt die koordinierte Weltzeit (Coordinated Universal Time, UTC) für die Anforderung an. Weitere Informationen finden Sie unter Autorisieren von Anforderungen an Azure Storage.
`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, undurchsichtigen Wert mit einem Zeichenlimit von 1 Kibibyte (KiB) bereit, der beim Konfigurieren der Protokollierung in den Protokollen aufgezeichnet wird. Es wird dringend empfohlen, diesen Header zu verwenden, um clientseitige Aktivitäten mit Anforderungen zu korrelieren, die der Server empfängt. Weitere Informationen finden Sie unter Überwachen von Azure Queue Storage.

Anforderungstext

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. Ein Zeitentwurfsgeber T trennt die Datums- und Uhrzeitteile der Zeichenfolge, und ein Zeitzonen-Designator TZD gibt eine 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>

Beispiel für eine Anforderung

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>

Antwort

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

Statuscode

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

Weitere Informationen zu status Codes finden Sie unter Status- und Fehlercodes.

Antwortheader

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`	Identifiziert eindeutig die Anforderung, die gestellt wurde, und kann zur Problembehandlung für die Anforderung verwendet werden. Weitere Informationen finden Sie unter Problembehandlung bei API-Vorgängen.
`x-ms-version`	Gibt die Warteschlangendienstversion an, die zum Ausführen der Anforderung verwendet wurde. Dieser Header wird für Anforderungen zurückgegeben, die für Version 2009-09-19 und höher vorgenommen wurden.
`Date`	Ein UTC-Datums-/Uhrzeitwert, der vom Dienst generiert wird, der die Uhrzeit angibt, zu der die Antwort initiiert wurde.
`x-ms-client-request-id`	Dieser Header kann zum Behandeln von Anforderungen und entsprechenden Antworten verwendet werden. Der Wert dieses Headers ist gleich dem Wert des `x-ms-client-request-id` Headers, wenn er in der Anforderung vorhanden ist und der Wert nicht mehr als 1.024 sichtbare ASCII-Zeichen enthält. Wenn der `x-ms-client-request-id` Header in der Anforderung nicht vorhanden ist, ist er in der Antwort nicht vorhanden.

Beispiel für eine Antwort

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

Authorization

Dieser Vorgang kann nur vom Kontobesitzer aufgerufen werden.

Hinweise

Nur der Kontobesitzer kann auf Ressourcen in einer bestimmten Warteschlange zugreifen, es sei denn, der Besitzer hat eine gemeinsame Zugriffssignatur für eine Ressource innerhalb der Warteschlange ausgestellt.

Wenn Sie Berechtigungen für eine Warteschlange festlegen, werden die vorhandenen Berechtigungen ersetzt. Um die Berechtigungen der Warteschlange zu aktualisieren, rufen Sie Warteschlangen-ACL abrufen auf, um alle Zugriffsrichtlinien abzurufen, die der Warteschlange zugeordnet sind. Ändern Sie die Zugriffsrichtlinie, die Sie ändern möchten, und rufen Set Queue ACL Sie dann mit dem vollständigen Datensatz auf, um das Update auszuführen.

Einrichten gespeicherter Zugriffsrichtlinien

Eine gespeicherte Zugriffsrichtlinie kann die Startzeit, die Ablaufzeit und die Berechtigungen für die freigegebenen Zugriffssignaturen angeben, denen sie zugeordnet ist. Je nachdem, wie Sie den Zugriff auf Ihre Warteschlangenressource steuern möchten, können Sie alle diese Parameter in der gespeicherten Zugriffsrichtlinie angeben und sie aus der URL für die Freigegebene Zugriffssignatur weglassen. Auf diese Weise können Sie das Verhalten der zugeordneten Signatur jederzeit ändern oder widerrufen. Alternativ können Sie einen oder mehrere Zugriffsrichtlinienparameter in der gespeicherten Zugriffsrichtlinie und die anderen Parameter in der URL angeben. Schließlich können Sie alle Parameter für die 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 Einrichten von Zugriffsrichtlinien finden Sie unter Definieren einer gespeicherten Zugriffsrichtlinie.

Zusammen müssen die Shared Access Signature und die gespeicherte Zugriffsrichtlinie alle Felder enthalten, die zum Autorisieren der Signatur erforderlich sind. Wenn erforderliche Felder fehlen, schlägt die Anforderung fehl. Wenn ein Feld sowohl in der URL für die Freigabezugriffssignatur als auch in der gespeicherten Zugriffsrichtlinie angegeben wird, schlägt die Anforderung mit status Code 400 (Ungültige Anforderung) fehl.

Maximal fünf separate Zugriffsrichtlinien können jederzeit für eine einzelne Warteschlange festgelegt werden. Wenn mehr als fünf Zugriffsrichtlinien im Anforderungstext übergeben werden, gibt der Dienst status Code 400 (Ungültige Anforderung) zurück.

Wenn Sie eine gespeicherte Zugriffsrichtlinie für eine Warteschlange einrichten, kann es bis zu 30 Sekunden dauern, bis sie wirksam wird. Während dieses Intervalls schlägt eine freigegebene Zugriffssignatur, die der gespeicherten Zugriffsrichtlinie zugeordnet ist, mit status Code 403 (Verboten) fehl, bis die Zugriffsrichtlinie aktiv wird.

Weitere Informationen

Definieren einer gespeicherten Zugriffsrichtlinie
Abrufen einer Warteschlangen-ACL
Autorisieren von Anforderungen an Azure Storage
Status- und Fehlercodes

Freigeben über