Container-ACL abrufen
Der Get Container ACL-Vorgang ruft die Berechtigungen für den angegebenen Container ab. Die Berechtigungen geben an, ob auf Containerdaten öffentlich zugegriffen werden kann.
Ab Version 2009-09-19 bieten die Containerberechtigungen die folgenden Optionen für die Verwaltung des Containerzugriffs:
Vollständiger öffentlicher Lesezugriff: Container- und BLOB-Daten können über anonyme Anforderung gelesen werden. Clients können Blobs innerhalb des Containers über anonyme Anforderung aufzählen, jedoch keine Container innerhalb des Speicherkontos aufzählen.
Öffentlicher Lesezugriff für Blobs nur: Blobdaten in diesem Container können über anonyme Anforderung gelesen werden, Containerdaten sind jedoch nicht verfügbar. Clients können Blobs innerhalb des Containers nicht über anonyme Anforderung aufzählen.
Kein öffentlicher Lesezugriff: Container- und BLOB-Daten können nur vom Kontobesitzer gelesen werden.
Get Container ACL gibt auch Details zu allen Zugriffsrichtlinien auf Containerebene zurück, die für den Container angegeben sind, der mit freigegebenen Zugriffssignaturen verwendet werden kann. Weitere Informationen finden Sie unter Definieren einer gespeicherten Zugriffsrichtlinie.
Der gesamte öffentliche Zugriff auf den Container ist anonym, wie der Zugriff über eine Freigegebene Zugriffssignatur.
Bitten
Die Get Container ACL Anforderung kann wie folgt erstellt werden. Es wird empfohlen, HTTPS zu verwenden. Ersetzen Sie myaccount durch den Namen Ihres Speicherkontos:
| Methode | Anforderungs-URI | HTTP-Version |
|---|---|---|
GET/HEAD |
https://myaccount.blob.core.windows.net/mycontainer?restype=container&comp=acl |
HTTP/1.1 |
Emulierte Speicherdienstanforderung
Wenn Sie eine Anforderung für den emulierten Speicherdienst durchführen, geben Sie den Hostnamen des Emulators und den Blob Storage-Port als 127.0.0.1:10000an, gefolgt vom emulierten Namen des Speicherkontos:
| Methode | Anforderungs-URI | HTTP-Version |
|---|---|---|
GET/HEAD |
http://127.0.0.1:10000/devstoreaccount1/mycontainer?restype=container&comp=acl |
HTTP/1.1 |
Weitere Informationen finden Sie unter Verwenden des Azurite-Emulators für die lokale Azure Storage-Entwicklung.
URI-Parameter
Die folgenden zusätzlichen Parameter können für den Anforderungs-URI angegeben werden:
| Parameter | Beschreibung |
|---|---|
timeout |
Wahlfrei. Der parameter timeout wird in Sekunden ausgedrückt. Weitere Informationen finden Sie unter Festlegen von Timeouts für Blob Storage-Vorgänge. |
Fehlercodes anfordern
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-lease-id: <ID> |
Optional, Version 2012-02-12 und höher. Wenn sie angegeben ist, ist Get Container ACL nur erfolgreich, wenn die Lease des Containers aktiv ist und dieser ID entspricht. Wenn keine aktive Lease vorhanden ist oder die ID nicht übereinstimmt, wird 412 (Precondition Failed) zurückgegeben. |
x-ms-version |
Erforderlich für alle autorisierten Anforderungen. 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 Blob Storage. |
Anforderungstext
Nichts.
Antwort
Die Antwort enthält einen HTTP-Statuscode, einen Satz von Antwortheadern und einen Antworttext.
Statuscode
Ein erfolgreicher Vorgang gibt den Statuscode 200 (OK) zurück.
Informationen zu Statuscodes finden Sie unter Status- und Fehlercodes.
Antwortfehlercodes
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-blob-public-access |
Gibt an, ob auf Daten im Container öffentlich und auf die Zugriffsebene zugegriffen werden kann. Mögliche Werte sind: - container: Gibt den vollständigen öffentlichen Lesezugriff für Container- und BLOB-Daten an. Clients können Blobs innerhalb des Containers über anonyme Anforderung aufzählen, jedoch keine Container innerhalb des Speicherkontos aufzählen.- blob: Gibt den öffentlichen Lesezugriff für Blobs an. Blob-Daten in diesem Container können über anonyme Anforderung gelesen werden, containerdaten sind jedoch nicht verfügbar. Clients können Blobs innerhalb des Containers nicht über anonyme Anforderung aufzählen.- true: Versionen vor 2016-05-31. Gibt an, dass der Container für den vollständigen öffentlichen Lesezugriff mit einer Version vor 2009-09-19 markiert wurde. Ab Version 2016-05-31 wird dieser Wert stattdessen als container zurückgegeben.Wenn dieser Header in der Antwort nicht zurückgegeben wird, ist der Container für den Kontobesitzer privat. |
ETag |
Das Entitätstag für den Container. Wenn die Anforderungsversion 2011-08-18 oder höher ist, wird der ETag-Wert in Anführungszeichen eingeschlossen. |
Last-Modified |
Gibt das Datum und die Uhrzeit der letzten Änderung des Containers zurück. Das Datumsformat folgt RFC 1123. Weitere Informationen finden Sie unter Darstellen von Datums-/Uhrzeitwerten in Fehlercodes. Jeder Vorgang, der den Container oder seine Eigenschaften oder Metadaten ändert, aktualisiert den Zeitpunkt der letzten Änderung. Vorgänge für Blobs wirken sich nicht auf die Uhrzeit der letzten Änderung des Containers aus. |
x-ms-request-id |
Identifiziert die anforderung eindeutig, die durchgeführt wurde, und kann verwendet werden, um die Anforderung zu behandeln. Weitere Informationen finden Sie unter Problembehandlung für API-Vorgänge. |
x-ms-version |
Gibt die Dienstversion 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 |
Kann verwendet werden, um Anfragen und die entsprechenden Antworten zu behandeln. 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 dieser Header in der Antwort nicht vorhanden. |
Antworttext
Wenn für den Container eine Zugriffsrichtlinie auf Containerebene angegeben wurde, gibt Get Container ACL den signierten Bezeichner und die Zugriffsrichtlinie im Antworttext zurück.
<?xml version="1.0" encoding="utf-8"?>
<SignedIdentifiers>
<SignedIdentifier>
<Id>unique-value</Id>
<AccessPolicy>
<Start>start-time</Start>
<Expiry>expiry-time</Expiry>
<Permission>abbreviated-permission-list</Permission>
</AccessPolicy>
</SignedIdentifier>
</SignedIdentifiers>
Beispielantwort
Response Status:
HTTP/1.1 200 OK
Response Headers:
Transfer-Encoding: chunked
x-ms-blob-public-access: container
Date: Sun, 25 Sep 2011 20:28:22 GMT
ETag: "0x8CAFB82EFF70C46"
Last-Modified: Sun, 25 Sep 2011 19:42:18 GMT
x-ms-version: 2011-08-18
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0
<?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>rwd</Permission>
</AccessPolicy>
</SignedIdentifier>
</SignedIdentifiers>
Ermächtigung
Die Autorisierung ist beim Aufrufen eines Datenzugriffsvorgangs in Azure Storage erforderlich. Sie können den Get Container ACL Vorgang wie unten beschrieben autorisieren.
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.
Azure Storage unterstützt die Verwendung der Microsoft Entra-ID zum Autorisieren von Anforderungen an BLOB-Daten. Mit Der Microsoft Entra-ID können Sie azure role-based access control (Azure RBAC) verwenden, um Berechtigungen für einen Sicherheitsprinzipal zu erteilen. Der Sicherheitsprinzipal kann ein Benutzer, eine Gruppe, ein Anwendungsdienstprinzipal oder eine von Azure verwaltete Identität sein. Der Sicherheitsprinzipal wird von der Microsoft Entra-ID authentifiziert, um ein OAuth 2.0-Token zurückzugeben. Das Token kann dann verwendet werden, um eine Anforderung für den Blob-Dienst zu autorisieren.
Weitere Informationen zur Autorisierung mithilfe der Microsoft Entra-ID finden Sie unter Autorisieren des Zugriffs auf Blobs mithilfe von Microsoft Entra ID.
Erlaubnisse
Nachfolgend sind die RBAC-Aktion aufgeführt, die für einen Microsoft Entra-Benutzer, eine Gruppe, eine verwaltete Identität oder einen Dienstprinzipal erforderlich ist, um den Get Container ACL Vorgang aufzurufen, und die integrierte Azure RBAC-Rolle, die diese Aktion enthält:
- Azure RBAC-Aktion:Microsoft.Storage/storageAccounts/blobServices/containers/getAcl/action
- Rolle mit den geringsten Rechten:Storage Blob Data Owner
Weitere Informationen zum Zuweisen von Rollen mithilfe von Azure RBAC finden Sie unter Zuweisen einer Azure-Rolle für den Zugriff auf BLOB-Daten.
Bemerkungen
Nichts. Einzelheiten dazu, wie sich dieser Vorgang auf kosten auswirkt, finden Sie unter Abrechnungsinformationen.
Abrechnung
Preisanforderungen können von Clients stammen, die Blob Storage-APIs verwenden, entweder direkt über die BLOB Storage-REST-API oder aus einer Azure Storage-Clientbibliothek. Diese Anforderungen anfallen Gebühren pro Transaktion. Der Transaktionstyp wirkt sich auf die Belastung des Kontos aus. Lesen Sie z. B. Transaktionen, die einer anderen Abrechnungskategorie als dem Schreiben von Transaktionen zugerechnet werden. Die folgende Tabelle zeigt die Abrechnungskategorie für Get Container ACL Anforderungen basierend auf dem Speicherkontotyp:
| Operation | Speicherkontotyp | Abrechnungskategorie |
|---|---|---|
| Container-ACL abrufen | Premium-Block-BLOB Standard general-purpose v2 |
Andere Vorgänge |
| Container-ACL abrufen | Standard general-purpose v1 | Lesevorgänge |
Informationen zu den Preisen für die angegebene Abrechnungskategorie finden Sie unter Azure Blob Storage Pricing.
Siehe auch
Einschränken des Zugriffs auf Container und Blobs
Definieren einer gespeicherten Zugriffsrichtlinie
Container-ACL- festlegen
Autorisieren von Anforderungen an Azure Storage
Status- und Fehlercodes
Blob Storage-Fehlercodes