Freigeben über

Set Container ACL

  • Artikel

Der Set Container ACL-Vorgang legt die Berechtigungen für den angegebenen Container fest. Die Berechtigungen geben an, ob öffentlicher Zugriff auf BLOBs in einem Container zulässig ist.

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 Anforderungen 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, aber Containerdaten sind nicht verfügbar. Clients können Blobs innerhalb des Containers nicht über eine anonyme Anforderung aufzählen.

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

Mit Set Container ACL wird außerdem eine gespeicherte Zugriffsrichtlinie für die Verwendung mit SAS (Shared Access Signatures, Signaturen für gemeinsamen Zugriff) festgelegt. 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 Set 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
PUT 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 ausführen, geben Sie den Emulatorhostnamen und den Port des Blob-Diensts mit 127.0.0.1:10000 an, gefolgt vom Namen des emulierten Speicherkontos:

Methode Anforderungs-URI HTTP-Version
PUT 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

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

Parameter BESCHREIBUNG
timeout Optional. Der timeout-Parameter wird in Sekunden angegeben. Weitere Informationen finden Sie unter Festlegen von Timeouts für Blobdienstvorgä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-blob-public-access Optional. Gibt an, ob öffentlicher Zugriff auf Daten im Container zulässig ist, und gibt die Zugriffsebene an. 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, aber Containerdaten sind nicht verfügbar. Clients können Blobs innerhalb des Containers nicht über eine anonyme Anforderung aufzählen.

Wenn dieser Header nicht in der Anforderung enthalten ist, sind die Containerdaten für den Kontobesitzer privat.

Beachten Sie, dass das Festlegen des öffentlichen Zugriffs für einen Container in einem Azure Storage Premium-Konto nicht zulässig ist.
x-ms-lease-id: <ID> Optional, Version 2012-02-12 und höher. Wenn angegeben, ist nur erfolgreich, Set Container ACL wenn die Lease des Containers aktiv ist und dieser ID entspricht. Wenn keine aktive Lease vorhanden ist oder die ID nicht übereinstimmt, wird 412 (Vorbedingungsfehler) zurückgegeben.
x-ms-client-request-id Optional. Stellt einen vom Client generierten, undurchsichtigen Wert mit einem Zeichenlimit von 1 Kibibyte (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 Azure Blob Storage.

Dieser Vorgang unterstützt zudem die Verwendung von bedingten Headern zum Ausführen des Vorgangs, wobei eine bestimmte Bedingung erfüllt sein muss. Weitere Informationen finden Sie unter Angeben von bedingten Headern für Blobdienstvorgänge.

Anforderungstext

Sie geben eine gespeicherte Zugriffsrichtlinie an, indem Sie im Anforderungstext für den Set Container 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.fffffffTZD

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 fffffff die siebenstellige Darstellung der Millisekunden. Ein Zeitdesignator T trennt die Datums- und Uhrzeitteile der Zeichenfolge, und ein Zeitzonen-Bezeichner 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.blob.core.windows.net/mycontainer?restype=container&comp=acl HTTP/1.1  
  
Request Headers:  
x-ms-version: 2011-08-18  
x-ms-date: Sun, 25 Sep 2011 00:42:49 GMT  
x-ms-blob-public-access: container  
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>rwd</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 200 (OK) 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
ETag Das ETag 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 Headern.

Bei jedem Vorgang, durch den der Container, dessen Eigenschaften oder Metadaten geändert werden, wird die Uhrzeit der letzten Änderung aktualisiert. Darunter fällt auch das Festlegen von Berechtigungen für den Container. 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 Blobdienstversion 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 erfolgen.
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 entsprechende 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 er in der Antwort nicht vorhanden.

Beispiel für eine Antwort

Response Status:  
HTTP/1.1 200 OK  
  
Response Headers:  
Transfer-Encoding: chunked  
Date: Sun, 25 Sep 2011 22:42:55 GMT  
ETag: "0x8CB171613397EAB"  
Last-Modified: Sun, 25 Sep 2011 22:42:55 GMT  
x-ms-version: 2011-08-18  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0

Authorization

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

Hinweise

Nur der Kontobesitzer hat Zugriff auf Ressourcen in einem bestimmten Container, es sei denn, der Besitzer hat durch Festlegen der Berechtigungen für den Container öffentlichen Zugriff auf Containerressourcen zugelassen oder eine SAS für eine Ressource im Container ausgegeben.

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

Aktivieren des anonymen öffentlichen Zugriffs auf Containerdaten

Um anonymen öffentlichen Lesezugriff auf Containerdaten zu aktivieren, rufen Sie Set Container ACL auf, und legen Sie dabei den x-ms-blob-public-access-Header auf container oder blob fest. Um den anonymen Zugriff zu deaktivieren, rufen Sie Set Container ACL auf, ohne den x-ms-blob-public-access-Header anzugeben.

Wenn Sie x-ms-blob-public-access auf blob festlegen, können Clients die folgenden Vorgänge anonym aufrufen:

Wenn Sie x-ms-blob-public-access auf container festlegen, können Clients die folgenden Vorgänge anonym aufrufen:

Einrichten von Zugriffsrichtlinien auf Containerebene

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 Ihren Container oder Ihre Blobressource 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 zugehörigen 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 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 einen einzelnen Container festgelegt werden. Wenn mehr als fünf Zugriffsrichtlinien im Anforderungstext übergeben werden, gibt der Dienst status Code 400 (Ungültige Anforderung) zurück.

Eine SAS für einen Container oder ein BLOB kann unabhängig davon ausgegeben werden, ob Containerdaten für anonymen Lesezugriff verfügbar sind. Mit einer SAS lässt sich genauer steuern, wie, wann und für wen eine Ressource verfügbar gemacht wird.

Hinweis

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

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 Set Container ACL Anforderungen basierend auf dem Speicherkontotyp:

Vorgang Speicherkontotyp Abrechnungskategorie
Set Container ACL Premium, Blockblob
Standard „Allgemein v2“		 Weitere Vorgänge
Set Container ACL Standard „Allgemein v1“ Schreibvorgänge

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
Delegieren des Zugriffs mit einer Shared Access Signature
Erstellen und Verwenden einer Shared Access Signature
Definieren einer gespeicherten Zugriffsrichtlinie
Get Container ACL
Autorisieren von Anforderungen an Azure Storage
Status- und Fehlercodes
Blobdienstfehlercodes