Freigeben über

Festlegen der Warteschlangen-ACL

  • Artikel

Der vorgang Set Queue ACL 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.

Anmerkung

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

Bitten

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 an den emulierten Speicherdienst stellen, geben Sie den Emulatorhost und den Warteschlangendienstport als 127.0.0.1:10001an, gefolgt vom emulierten Speicherkontonamen:

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 die lokale Azure Storage-Entwicklung.

URI-Parameter

Sie können die folgenden zusätzlichen Parameter für den Anforderungs-URI angeben:

Parameter Beschreibung
timeout Wahlfrei. Der parameter timeout wird in Sekunden ausgedrückt. 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 (UTC) für die Anforderung an. Weitere Informationen finden Sie unter Autorisieren von Anforderungen an Azure Storage.
x-ms-version Wahlfrei. Gibt die Version des Vorgangs an, der für diese Anforderung verwendet werden soll. Weitere Informationen finden Sie unter Versionsverwaltung für die Azure Storage-Dienste.
x-ms-client-request-id Wahlfrei. Stellt einen vom Client generierten, undurchsichtigen Wert mit einem 1-Kibibyte-Zeichenlimit (KiB) bereit, der in den Protokollen aufgezeichnet wird, wenn die Protokollierung konfiguriert ist. 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

Um eine gespeicherte Zugriffsrichtlinie anzugeben, stellen Sie eine eindeutige ID und Zugriffsrichtlinie im Anforderungstext für den Set Queue ACL-Vorgang bereit.

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

Die Felder Start und Expiry müssen als UTC-Zeiten ausgedrückt werden und müssen einem gültigen ISO 8061-Format entsprechen. Unterstützte ISO 8061-Formate umfassen Folgendes:

  • YYYY-MM-DD
  • YYYY-MM-DDThh:mmTZD
  • YYYY-MM-DDThh:mm:ssTZD
  • YYYY-MM-DDThh:mm:ss.ffffffTZD

Für den Datumsteil dieser Formate ist YYYY eine vierstellige Jahresdarstellung, MM eine zweistellige Monatsdarstellung und DD eine zweistellige Tagesdarstellung ist. Für den Zeitteil ist hh die Stundendarstellung in 24-Stunden-Notation, mm die zweistellige Minutendarstellung, ss die zweistellige Zweite Darstellung und ffffff die sechsstellige Millisekundendarstellung ist. Ein Zeitsenzeichner T trennt die Datums- und Uhrzeitabschnitte der Zeichenfolge, und ein Zeitzonen-Kennzeichner 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>

Beispielanforderung

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 einen HTTP-Statuscode und eine Reihe von Antwortheadern.

Statuscode

Ein erfolgreicher Vorgang gibt den Statuscode 204 (Kein Inhalt) zurück.

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

Antwortheader

Die Antwort für diesen Vorgang enthält die folgenden Header. Die Antwort kann auch zusätzliche Standard-HTTP-Header enthalten. Alle Standardheader entsprechen der HTTP/1.1-Protokollspezifikation.

Antwortheader Beschreibung
x-ms-request-id Identifiziert eindeutig die Anforderung, die durchgeführt wurde, und kann zur Problembehandlung der Anforderung verwendet werden. Weitere Informationen finden Sie unter Problembehandlung für API-Vorgänge.
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.

Beispielantwort

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

Ermächtigung

Die Autorisierung ist beim Aufrufen eines Datenzugriffsvorgangs in Azure Storage erforderlich. Sie können den Set Queue ACL Vorgang mithilfe der Microsoft Entra-ID oder des freigegebenen Schlüssels autorisieren.

Um den Set Queue ACL Vorgang mithilfe der Microsoft Entra-ID zu autorisieren, benötigt der Sicherheitsprinzipal eine benutzerdefinierte Azure RBAC-Rolle, die die folgende RBAC-Aktion enthält: Microsoft.Storage/storageAccounts/queueServices/queues/setAcl/action.

Wichtig

Microsoft empfiehlt die Verwendung der Microsoft Entra-ID mit verwalteten Identitäten, um Anforderungen an Azure Storage zu autorisieren. Die Microsoft Entra-ID bietet eine bessere Sicherheit und Benutzerfreundlichkeit im Vergleich zur Shared Key-Autorisierung.

Bemerkungen

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 Sie dann Set Queue ACL mit dem vollständigen Satz von Daten auf, um die Aktualisierung durchzuführen.

Einrichten von gespeicherten 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 innerhalb der gespeicherten Zugriffsrichtlinie angeben und von der URL für die Signatur für den freigegebenen Zugriff weglassen. Dadurch können Sie das Verhalten der zugehörigen Signatur jederzeit ändern oder widerrufen. Sie können auch einen oder mehrere Zugriffsrichtlinienparameter innerhalb der gespeicherten Zugriffsrichtlinie und die anderen Auf 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 zu widerrufen, aber nicht, um das Verhalten zu ändern. Weitere Informationen zum Einrichten von Zugriffsrichtlinien finden Sie unter Definieren einer gespeicherten Zugriffsrichtlinie.

Zusammen müssen die Signatur für den freigegebenen Zugriff und die Richtlinie für den gespeicherten Zugriff 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 der freigegebenen Zugriffssignatur als auch in der gespeicherten Zugriffsrichtlinie angegeben wird, schlägt die Anforderung mit dem Statuscode 400 (Ungültige Anforderung) fehl.

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

Wenn Sie eine gespeicherte Zugriffsrichtlinie in einer 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 dem Statuscode 403 (Verboten) fehl, bis die Zugriffsrichtlinie aktiv wird.

Siehe auch

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