Freigeben über

Get Container ACL

  • Artikel

Der Get Container ACL-Vorgang ruft die Berechtigungen für den angegebenen Container ab. Mit den Berechtigungen wird angegeben, ob auf die Containerdaten öffentlich zugegriffen werden kann.

Ab Version 2009-09-19 bieten die Containerberechtigungen die folgenden Optionen zum Verwalten des Containerzugriffs:

  • Vollständiger öffentlicher Lesezugriff: Container- und Blobdaten können über eine anonyme Anforderung gelesen werden. Clients können Blobs innerhalb des Containers über eine anonyme Anforderung aufzählen, aber keine Container innerhalb des Speicherkontos auflisten.

  • Öffentlicher Lesezugriff nur für Blobs: Blobdaten in diesem Container können über eine anonyme Anforderung gelesen werden, Containerdaten sind jedoch nicht verfügbar. Clients können Blobs innerhalb des Containers nicht über eine anonyme Anforderung aufzählen.

  • Kein öffentlicher Lesezugriff: Container- und Blobdaten können nur vom Kontobesitzer gelesen werden.

Get Container ACL Gibt außerdem 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.

Sämtlicher Zugriff auf den Container ist anonym, wie auch der Zugriff über eine SAS.

Anforderung

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 stellen, geben Sie den Hostnamen des Emulators und den Blob Storage-Port als 127.0.0.1:10000an, gefolgt vom Namen des emulierten 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 lokale Azure Storage-Entwicklung.

URI-Parameter

Die folgenden zusätzlichen Parameter können für den Anforderungs-URI angegeben werden:

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

Anforderungsfehlercodes

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-lease-id: <ID> Optional, Version 2012-02-12 und höher. Wenn dies angegeben ist, ist nur erfolgreich, Get Container ACL wenn die Lease des Containers aktiv ist und dieser ID entspricht. Wenn keine aktive Lease vorhanden ist oder die ID nicht übereinstimmt, 412 (Precondition Failed) wird zurückgegeben.
x-ms-version Erforderlich für alle autorisierten Anforderungen. 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 Azure Blob Storage.

Anforderungstext

Keine.

Antwort

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

Statuscode

Bei einem erfolgreichen Vorgang wird der Statuscode 200 (OK) zurückgegeben.

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

Antwortfehlercodes

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-blob-public-access Gibt an, ob auf Daten im Container öffentlich zugegriffen werden kann, außerdem wird die Zugriffsebene angegeben. Mögliche Werte sind:

- container: Gibt den vollständigen öffentlichen Lesezugriff für Container- und Blobdaten an. Clients können Blobs innerhalb des Containers über eine anonyme Anforderung aufzählen, aber keine Container innerhalb des Speicherkontos auflisten.
- blob: Gibt öffentlichen Lesezugriff für Blobs an. Blobdaten in diesem Container können über eine anonyme Anforderung gelesen werden, Containerdaten sind jedoch nicht verfügbar. Clients können Blobs innerhalb des Containers nicht über eine anonyme Anforderung aufzählen.
- true: Nur Versionen vor 2016-05-31. Gibt an, dass der Container mit einer Version vor 2009-09-19 für den vollständigen öffentlichen Lesezugriff 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 entspricht RFC 1123. Weitere Informationen finden Sie unter Darstellen von Datums-/Uhrzeitwerten in Fehlercodes.

Bei jedem Vorgang, durch den der Container, seine Eigenschaften oder seine Metadaten geändert werden, wird der Zeitpunkt der letzten Änderung aktualisiert. Vorgänge für Blobs wirken sich nicht auf den Zeitpunkt der letzten Änderung des Containers aus.
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 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 Anforderungen und ihre 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>

Beispiel für eine Antwort

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>

Authorization

Der Get Container ACL Vorgang unterstützt nur die Autorisierung gemeinsam genutzter Schlüssel.

Hinweise

Nur der Kontobesitzer kann Daten in einem bestimmten Speicherkonto lesen, es sei denn, der Kontobesitzer hat angegeben, dass Blobs innerhalb des Containers für den öffentlichen Lesezugriff verfügbar sind oder Ressourcen im Container über eine Shared Access Signature verfügbar gemacht hat.

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. Für diese Anforderungen fallen Gebühren pro Transaktion an. Die Art der Transaktion wirkt sich auf die Belastung des Kontos aus. Beispielsweise werden Lesetransaktionen in eine andere Abrechnungskategorie als das Schreiben von Transaktionen angewendet. Die folgende Tabelle zeigt die Abrechnungskategorie für Get Container ACL Anforderungen basierend auf dem Speicherkontotyp:

Vorgang Speicherkontotyp Abrechnungskategorie
Get Container ACL Premium, Blockblob
Standard „Allgemein v2“		 Weitere Vorgänge
Get Container ACL Standard „Allgemein v1“ Dient zum Lesen von Vorgängen.

Weitere Informationen zu Preisen für die angegebene Abrechnungskategorie finden Sie unter Azure Blob Storage Preise.

Weitere Informationen

Einschränken des Zugriffs auf Container und Blobs
Definieren einer gespeicherten Zugriffsrichtlinie
Set Container ACL
Autorisieren von Anforderungen an Azure Storage
Status- und Fehlercodes
Blob Storage-Fehlercodes