Container-ACL ophalen

De Get Container ACL-bewerking haalt de machtigingen voor de opgegeven container op. De machtigingen geven aan of containergegevens openbaar toegankelijk zijn.

Vanaf versie 2009-09-19 bieden de containermachtigingen de volgende opties voor het beheren van containertoegang:

• volledige openbare leestoegang: container- en blobgegevens kunnen worden gelezen via anonieme aanvraag. Clients kunnen blobs in de container opsommen via anonieme aanvragen, maar ze kunnen geen containers in het opslagaccount opsommen.

• openbare leestoegang voor blobs alleen: blobgegevens in deze container kunnen worden gelezen via anonieme aanvraag, maar containergegevens zijn niet beschikbaar. Clients kunnen geen blobs in de container opsommen via anonieme aanvraag.

• Geen openbare leestoegang: container- en blobgegevens kunnen alleen worden gelezen door de accounteigenaar.

Get Container ACL retourneert ook details over toegangsbeleid op containerniveau dat is opgegeven in de container die kan worden gebruikt met handtekeningen voor gedeelde toegang. Zie Een opgeslagen toegangsbeleid definiërenvoor meer informatie.

Alle openbare toegang tot de container is anoniem, net als toegang via een Shared Access Signature.

Verzoek

De Get Container ACL aanvraag kan als volgt worden samengesteld. U wordt aangeraden HTTPS te gebruiken. Vervang myaccount- door de naam van uw opslagaccount:

Methode	Aanvraag-URI	HTTP-versie
GET/HEAD	https://myaccount.blob.core.windows.net/mycontainer?restype=container&comp=acl	HTTP/1.1

Emulated storage-serviceaanvraag

Wanneer u een aanvraag indient voor de geëmuleerde opslagservice, geeft u de hostnaam van de emulator en de Blob Storage-poort op als 127.0.0.1:10000, gevolgd door de geëmuleerde naam van het opslagaccount:

Methode	Aanvraag-URI	HTTP-versie
GET/HEAD	http://127.0.0.1:10000/devstoreaccount1/mycontainer?restype=container&comp=acl	HTTP/1.1

Zie De Azurite-emulator gebruiken voor lokale Azure Storage-ontwikkelingvoor meer informatie.

URI-parameters

De volgende aanvullende parameters kunnen worden opgegeven voor de aanvraag-URI:

Parameter	Beschrijving
timeout	Facultatief. De parameter timeout wordt uitgedrukt in seconden. Zie Time-outs instellen voor Blob Storage-bewerkingenvoor meer informatie.

Foutcodes aanvragen

De vereiste en optionele aanvraagheaders worden beschreven in de volgende tabel:

Aanvraagheader	Beschrijving
Authorization	Vereist. Hiermee geeft u het autorisatieschema, de accountnaam en de handtekening op. Zie Aanvragen autoriseren voor Azure Storagevoor meer informatie.
Date of x-ms-date	Vereist. Hiermee geeft u de Coordinated Universal Time (UTC) voor de aanvraag. Zie Aanvragen autoriseren voor Azure Storagevoor meer informatie.
x-ms-lease-id: <ID>	Optioneel, versie 2012-02-12 en hoger. Als deze is opgegeven, slaagt Get Container ACL alleen als de lease van de container actief is en overeenkomt met deze id. Als er geen actieve lease is of de id niet overeenkomt, wordt 412 (Precondition Failed) geretourneerd.
x-ms-version	Vereist voor alle geautoriseerde aanvragen. Hiermee geeft u de versie van de bewerking die moet worden gebruikt voor deze aanvraag. Zie Versiebeheer voor de Azure Storage-servicesvoor meer informatie.
x-ms-client-request-id	Facultatief. Biedt een door de client gegenereerde, ondoorzichtige waarde met een tekenlimiet van 1 kibibyte (KiB) die wordt vastgelegd in de logboeken wanneer logboekregistratie is geconfigureerd. We raden u ten zeerste aan deze header te gebruiken om activiteiten aan de clientzijde te correleren met aanvragen die de server ontvangt. Zie Azure Blob Storage-bewaken voor meer informatie.

Aanvraagbody

Geen.

Antwoord

Het antwoord bevat een HTTP-statuscode, een set antwoordheaders en een hoofdtekst van het antwoord.

Statuscode

Een geslaagde bewerking retourneert statuscode 200 (OK).

Zie Status en foutcodesvoor meer informatie over statuscodes.

Antwoordfoutcodes

Het antwoord voor deze bewerking bevat de volgende headers. Het antwoord kan ook aanvullende standaard HTTP-headers bevatten. Alle standaardheaders voldoen aan de HTTP/1.1-protocolspecificatie.

Antwoordheader	Beschrijving
x-ms-blob-public-access	Hiermee wordt aangegeven of gegevens in de container openbaar en het toegangsniveau kunnen worden geopend. Mogelijke waarden zijn: - container: geeft volledige openbare leestoegang voor container- en blobgegevens aan. Clients kunnen blobs in de container opsommen via anonieme aanvragen, maar ze kunnen geen containers in het opslagaccount opsommen. - blob: Geeft openbare leestoegang voor blobs aan. Blobgegevens in deze container kunnen worden gelezen via anonieme aanvraag, maar containergegevens zijn niet beschikbaar. Clients kunnen geen blobs in de container opsommen via anonieme aanvraag. - true: versies ouder dan 2016-05-31. Geeft aan dat de container is gemarkeerd voor volledige openbare leestoegang met een versie die ouder is dan 2009-09-19. Vanaf versie 2016-05-31 wordt deze waarde als container geretourneerd. Als deze header niet wordt geretourneerd in het antwoord, is de container privé voor de accounteigenaar.
ETag	De entiteitstag voor de container. Als de aanvraagversie 2011-08-18 of hoger is, wordt de ETag-waarde tussen aanhalingstekens geplaatst.
Last-Modified	Retourneert de datum en tijd waarop de container voor het laatst is gewijzigd. De datumnotatie volgt RFC 1123. Zie Datum/tijd-waarden weergeven in foutcodesvoor meer informatie. Elke bewerking die de container of de eigenschappen of metagegevens wijzigt, wordt de laatste wijzigingstijd bijgewerkt. Bewerkingen op blobs hebben geen invloed op de laatste wijzigingstijd van de container.
x-ms-request-id	Identificeer de aanvraag die is gemaakt en kan worden gebruikt om problemen met de aanvraag op te lossen. Zie Problemen met API-bewerkingen oplossenvoor meer informatie.
x-ms-version	Geeft de serviceversie aan die is gebruikt om de aanvraag uit te voeren. Deze header wordt geretourneerd voor aanvragen die zijn gedaan op basis van versie 2009-09-19 en hoger.
Date	Een UTC-datum/tijdwaarde die wordt gegenereerd door de service, wat de tijd aangeeft waarop het antwoord is gestart.
x-ms-client-request-id	Kan worden gebruikt voor het oplossen van problemen met aanvragen en de bijbehorende antwoorden. De waarde van deze header is gelijk aan de waarde van de x-ms-client-request-id header als deze aanwezig is in de aanvraag en de waarde niet meer dan 1024 zichtbare ASCII-tekens bevat. Als de x-ms-client-request-id header niet aanwezig is in de aanvraag, is deze header niet aanwezig in het antwoord.

Hoofdtekst van antwoord

Als er een toegangsbeleid op containerniveau is opgegeven voor de container, retourneert Get Container ACL de ondertekende id en het toegangsbeleid in de hoofdtekst van het antwoord.

<?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>  

Voorbeeldantwoord

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>  
  

Machtiging

Autorisatie is vereist bij het aanroepen van een bewerking voor gegevenstoegang in Azure Storage. U kunt de Get Container ACL bewerking autoriseren zoals hieronder wordt beschreven.

Belangrijk

Microsoft raadt aan om Microsoft Entra ID met beheerde identiteiten te gebruiken om aanvragen voor Azure Storage te autoriseren. Microsoft Entra ID biedt superieure beveiliging en gebruiksgemak in vergelijking met autorisatie van gedeelde sleutels.

Microsoft Entra ID (aanbevolen)

Azure Storage ondersteunt het gebruik van Microsoft Entra ID om aanvragen voor blobgegevens te autoriseren. Met Microsoft Entra ID kunt u op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC) gebruiken om machtigingen te verlenen aan een beveiligingsprincipaal. De beveiligingsprincipaal kan een door een gebruiker, groep, toepassingsservice-principal of door Azure beheerde identiteit zijn. De beveiligingsprincipaal wordt geverifieerd door de Microsoft Entra-id om een OAuth 2.0-token te retourneren. Het token kan vervolgens worden gebruikt om een aanvraag te autoriseren voor de Blob-service.

Zie Toegang tot blobs autoriseren met behulp van Microsoft Entra IDvoor meer informatie over autorisatie met Behulp van Microsoft Entra ID.

Machtigingen

Hieronder vindt u de RBAC-actie die nodig is voor een Microsoft Entra-gebruiker, groep, beheerde identiteit of service-principal om de Get Container ACL-bewerking aan te roepen, en de minst bevoorrechte ingebouwde Azure RBAC-rol die deze actie omvat:

• Azure RBAC-actie:Microsoft.Storage/storageAccounts/blobServices/containers/getAcl/action
• ingebouwde rol met minimale bevoegdheden:eigenaar van opslagblobgegevens

Zie Een Azure-rol toewijzen voor toegang tot blobgegevensvoor meer informatie over het toewijzen van rollen met behulp van Azure RBAC.

gedeelde sleutel

De Get Container ACL-bewerking ondersteunt autorisatie van gedeelde sleutels. Autoriseren met accountsleutels wordt niet aanbevolen voor de meeste scenario's, omdat het minder veilig is.

Microsoft raadt u aan de toewijzing van gedeelde sleutelautorisatie voor het opslagaccount indien mogelijk ongedaan te maken. Zie Autorisatie voorkomen met gedeelde sleutelvoor meer informatie.

Opmerkingen

Geen. Zie factureringsgegevens voor meer informatie over hoe deze bewerking van invloed is op de kosten.

Facturering

Prijsaanvragen kunnen afkomstig zijn van clients die Blob Storage-API's gebruiken, rechtstreeks via de Blob Storage REST API of vanuit een Azure Storage-clientbibliotheek. Deze aanvragen maken kosten per transactie. Het type transactie is van invloed op de manier waarop het account in rekening wordt gebracht. Leestransacties worden bijvoorbeeld opgebouwd tot een andere factureringscategorie dan schrijftransacties. In de volgende tabel ziet u de factureringscategorie voor Get Container ACL aanvragen op basis van het type opslagaccount:

Operatie	Type opslagaccount	Factureringscategorie
Container-ACL ophalen	Premium blok-blob Standaard algemeen gebruik v2	Andere bewerkingen
Container-ACL ophalen	Standaard algemeen gebruik v1	Leesbewerkingen

Zie Prijzen voor Azure Blob Storagevoor meer informatie over prijzen voor de opgegeven factureringscategorie.

Zie ook

de toegang tot containers en blobs beperken
Een opgeslagen toegangsbeleid definiëren
container-ACL instellen
aanvragen autoriseren voor Azure Storage
status en foutcodes
Blob Storage-foutcodes