Set Container ACL

L'opération Set Container ACL définit les autorisations pour le conteneur spécifié. Les autorisations indiquent si les objets blob dans un conteneur sont accessibles publiquement.

À compter de la version 2009-09-19, les autorisations de conteneur fournissent les options suivantes pour gérer l’accès aux conteneurs :

• Accès total en lecture public : les données de conteneur et d'objet BLOB peuvent être lues via une demande anonyme. Les clients peuvent énumérer des objets blob dans le conteneur via une requête anonyme, mais ils ne peuvent pas énumérer les conteneurs dans le compte de stockage.

• Accès en lecture public pour les objets blob uniquement : Les données blob au sein de ce conteneur peuvent être lues via une demande anonyme, mais les données de conteneur ne sont pas disponibles. Les clients ne peuvent pas énumérer les objets blob dans le conteneur via une demande anonyme.

• Aucun accès en lecture public : Les données de conteneur et d'objet BLOB ne peuvent être lues que par le propriétaire du compte.

Set Container ACL définit également une stratégie d'accès stockée utilisable avec des signatures d'accès partagé. Pour plus d’informations, consultez Mise en place d’une stratégie d’accès stockée.

L'accès public au conteneur est anonyme, de même que l'accès via une signature d'accès partagé.

Requête

La demande Set Container ACL peut être construite comme indiqué ci-dessous. Nous vous recommandons d’utiliser HTTPS. Remplacez moncompte par le nom de votre compte de stockage :

Méthode	URI de demande	Version HTTP
PUT	https://myaccount.blob.core.windows.net/mycontainer?restype=container&comp=acl	HTTP/1.1

Demande de service de stockage émulée

Lorsque vous élaborez une demande pour le service de stockage émulé, spécifiez le nom d'hôte de l'émulateur et le port de service BLOB sous la forme 127.0.0.1:10000, suivi du nom de compte de stockage émulé :

Méthode	URI de demande	Version HTTP
PUT	http://127.0.0.1:10000/devstoreaccount1/mycontainer?restype=container&comp=acl	HTTP/1.1

Pour plus d’informations, consultez Utiliser l’émulateur Azurite à des fins de développement local pour Stockage Azure.

Paramètres URI

Vous pouvez spécifier les paramètres supplémentaires suivants dans l’URI de requête :

Paramètre	Description
timeout	facultatif. Le paramètre timeout est exprimé en secondes. Pour plus d’informations, consultez Définir des délais d’attente pour les opérations de service Blob.

En-têtes de requête

Les en-têtes de requête obligatoires et facultatifs sont décrits dans le tableau suivant :

En-tête de requête	Description
Authorization	Obligatoire. Spécifie le schéma d’autorisation, le nom du compte et la signature. Pour plus d’informations, consultez Autoriser les requêtes auprès du Stockage Azure.
Date ou x-ms-date	Obligatoire. Spécifie la date/heure en temps universel coordonné (UTC) pour la requête. Pour plus d’informations, consultez Autoriser les requêtes auprès du Stockage Azure.
x-ms-version	facultatif. Spécifie la version de l'opération à utiliser pour cette demande. Pour plus d'informations, consultez la page Contrôle de version pour les services de Stockage Microsoft Azure.
x-ms-blob-public-access	facultatif. Spécifie si les données dans le conteneur sont accessibles publiquement et le niveau d'accès. Les valeurs possibles incluent : - container: spécifie l’accès en lecture public complet pour les données de conteneur et d’objets blob. Les clients peuvent énumérer des objets blob dans le conteneur via une requête anonyme, mais ils ne peuvent pas énumérer les conteneurs dans le compte de stockage. - blob: Spécifie l’accès en lecture public pour les objets blob. Les données blob au sein de ce conteneur peuvent être lues via une demande anonyme, mais les données de conteneur ne sont pas disponibles. Les clients ne peuvent pas énumérer les objets blob dans le conteneur via une demande anonyme. Si cet en-tête n’est pas inclus dans la demande, les données de conteneur sont privées au propriétaire du compte. Notez que la définition de l’accès public pour un conteneur dans un compte Azure Stockage Premium n’est pas autorisée.
x-ms-lease-id: <ID>	Facultatif, version 2012-02-12 et ultérieure. S’il est spécifié, Set Container ACL réussit uniquement si le bail du conteneur est actif et correspond à cet ID. S’il n’y a pas de bail actif ou si l’ID ne correspond pas, 412 (Échec de la condition préalable) est retourné.
x-ms-client-request-id	facultatif. Fournit une valeur opaque générée par le client avec une limite de caractères de 1 kibioctet (Kio) enregistrée dans les journaux lors de la configuration de la journalisation. Nous vous recommandons vivement d’utiliser cet en-tête pour mettre en corrélation les activités côté client avec les demandes que le serveur reçoit. Pour plus d’informations, consultez Surveiller Stockage Blob Azure.

Cette opération prend également en charge l'utilisation d'en-têtes conditionnels pour exécuter l'opération uniquement si une condition est remplie. Pour plus d’informations, consultez Spécifier des en-têtes conditionnels pour les opérations de service Blob.

Corps de la demande

Pour spécifier une stratégie d'accès stockée, indiquez un identificateur unique et une stratégie d'accès dans le corps de la demande pour l'opération Set Container ACL.

L'élément SignedIdentifier comprend l'identificateur unique, comme indiqué dans l'élément Id, et les détails de la stratégie d'accès, comme indiqué dans l'élément AccessPolicy. La longueur maximale de l'identificateur unique est de 64 caractères.

Les champs Start et Expiry doivent être exprimés en heures UTC et doivent être dans un format ISO 8061 valide. Les formats ISO 8061 pris en charge sont notamment :

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

Pour la partie date de ces formats, YYYY est une représentation de l'année à quatre chiffres, MM est une représentation du mois à deux chiffres et DD est une représentation du jour à deux chiffres. Pour la partie heure, hh est la représentation de l'heure au format 24 heures, mm est la représentation des minutes à deux chiffres, ss est la représentation des secondes à deux chiffres et fffffff est la représentation des millisecondes à sept chiffres. Un désignateur T d’heure sépare les parties de date et d’heure de la chaîne, et un désignateur de fuseau horaire TZD spécifie un fuseau horaire.

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

Exemple de requête

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>  
  

response

La réponse inclut un code d'état HTTP et un ensemble d'en-têtes de réponse.

Code d’état

Une opération réussie envoie le code d'état 200 (OK).

Pour plus d’informations sur les codes status, consultez Codes d’état et d’erreur.

En-têtes de réponse

La réponse de l'opération inclut les en-têtes suivants. La réponse peut aussi inclure des en-têtes HTTP standard supplémentaires. Tous les en-têtes standard sont conformes à la spécification du protocole HTTP/1.1.

En-tête de réponse	Description
ETag	L'ETag du conteneur. Si la version de la demande est 2011-08-18 ou version ultérieure, la valeur ETag est placée entre guillemets.
Last-Modified	Retourne la date et l’heure de la dernière modification du conteneur. Le format de date est conforme à la RFC 1123. Pour plus d’informations, consultez Représenter des valeurs de date/heure dans les en-têtes. Toute opération qui modifie le conteneur ou ses propriétés ou métadonnées met à jour l'heure de la dernière modification, notamment la définition des autorisations du conteneur. Les opérations sur les objets blob n’affectent pas l’heure de dernière modification du conteneur.
x-ms-request-id	Identifie de manière unique la demande qui a été effectuée et peut être utilisée pour résoudre la demande. Pour plus d’informations, consultez Résoudre les problèmes liés aux opérations d’API
x-ms-version	Indique la version du service Blob utilisée pour exécuter la demande. Cet en-tête est renvoyé pour les demandes effectuées avec la version 2009-09-19 ou une version ultérieure.
Date	Valeur de date/heure UTC générée par le service, qui indique l’heure à laquelle la réponse a été lancée.
x-ms-client-request-id	Peut être utilisé pour résoudre les demandes et les réponses correspondantes. La valeur de cet en-tête est égale à la valeur de l’en-tête x-ms-client-request-id s’il est présent dans la requête et que la valeur ne contient pas plus de 1 024 caractères ASCII visibles. Si l’en-tête x-ms-client-request-id n’est pas présent dans la demande, il ne sera pas présent dans la réponse.

Exemple de réponse

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  

Autorisation

L’opération Set Container ACL prend uniquement en charge l’autorisation de clé partagée.

Remarques

Seul le propriétaire du compte peut accéder aux ressources dans un conteneur spécifique, sauf si le propriétaire a spécifié que les ressources conteneur sont disponibles pour un accès public en définissant des autorisations sur le conteneur, ou s'il a émis une signature d'accès partagé pour une ressource au sein du conteneur.

Lorsque vous définissez des autorisations pour un conteneur, les autorisations existantes sont remplacées. Pour mettre à jour les autorisations du conteneur, appelez Get Container ACL pour récupérer toutes les stratégies d’accès associées au conteneur. Modifiez la stratégie d’accès que vous souhaitez modifier, puis appelez Set Container ACL avec l’ensemble complet de données pour effectuer la mise à jour.

Activer l’accès public anonyme sur les données conteneur

Pour activer l'accès en lecture public anonyme sur les données de conteneur, appelez Set Container ACL avec l'en-tête x-ms-blob-public-access défini à la valeur container ou blob. Pour désactiver l'accès anonyme, appelez Set Container ACL sans spécifier l'en-tête x-ms-blob-public-access.

Si vous définissez x-ms-blob-public-access à la valeur blob, les clients peuvent appeler les opérations suivantes de façon anonyme :

• Get Blob

• Get Blob Properties

• Get Blob Metadata

• Obtenir la liste de blocs (pour la liste de blocs validée uniquement)

• Obtenir les portées de page

Si vous définissez x-ms-blob-public-access à la valeur container, les clients peuvent appeler les opérations suivantes de façon anonyme :

• Opérations d’accès aux objets blob répertoriées dans la section précédente.

• Get Container Properties

• Get Container Metadata

• Lister les objets blob

Établir des stratégies d’accès au niveau du conteneur

Une stratégie d’accès stockée peut spécifier l’heure de début, l’heure d’expiration et les autorisations pour les signatures d’accès partagé auxquelles elle est associée. Selon la façon dont vous souhaitez contrôler l’accès à votre conteneur ou à votre ressource blob, vous pouvez spécifier tous ces paramètres dans la stratégie d’accès stockée et les omettre de l’URL de la signature d’accès partagé. Ce faisant, vous pouvez modifier le comportement de la signature associée à tout moment ou la révoquer. Vous pouvez également spécifier un ou plusieurs paramètres de stratégie d’accès dans la stratégie d’accès stockée et les autres sur l’URL. Enfin, vous pouvez spécifier tous les paramètres sur l’URL. Dans ce cas, vous pouvez utiliser la stratégie d'accès stockée pour révoquer la signature et non pour modifier son comportement. Pour plus d’informations, consultez Mise en place d’une stratégie d’accès stockée.

Ensemble, la signature d’accès partagé et la stratégie d’accès stockée doivent inclure tous les champs requis pour autoriser la signature. Si des champs obligatoires sont manquants, la demande échoue. De même, si un champ est spécifié dans l’URL de signature d’accès partagé et dans la stratégie d’accès stockée, la demande échoue avec status code 400 (requête incorrecte).

Au maximum, cinq stratégies d’accès distinctes peuvent être définies pour un seul conteneur à tout moment. Si plus de cinq stratégies d’accès sont passées dans le corps de la demande, le service retourne status code 400 (requête incorrecte).

Une signature d'accès partagé peut être émise dans un conteneur ou un objet blob indépendamment du fait que des données de conteneur soient disponibles pour un accès en lecture anonyme. Une signature d'accès partagé fournit davantage de contrôle sur la façon dont une ressource est rendue accessible, sur qui peut y avoir accès et quand.

Notes

Lorsque vous établissez une stratégie d’accès stocké sur un conteneur, l’application de la stratégie peut prendre jusqu’à 30 secondes. Pendant cet intervalle, jusqu’à ce que la stratégie soit active, une signature d’accès partagé associée à la stratégie d’accès stockée échoue avec status code 403 (Interdit).

Facturation

Les demandes de tarification peuvent provenir de clients qui utilisent des API Stockage Blob, soit directement via l’API REST Stockage Blob, soit à partir d’une bibliothèque cliente stockage Azure. Ces demandes cumulent des frais par transaction. Le type de transaction affecte la façon dont le compte est facturé. Par exemple, les transactions de lecture sont comptabilisées dans une catégorie de facturation différente de celle des transactions en écriture. Le tableau suivant montre la catégorie de facturation pour Set Container ACL les demandes en fonction du type de compte de stockage :

Opération	Type de compte de stockage	Catégorie de facturation
Set Container ACL	Objet blob de blocs Premium Usage général v2 Standard	Autres opérations
Set Container ACL	Usage général v1 standard	Opérations d’écriture

Pour en savoir plus sur la tarification de la catégorie de facturation spécifiée, consultez Stockage Blob Azure Tarification.

Voir aussi

Restreindre l’accès aux conteneurs et objets blob
Déléguer l’accès avec une signature d’accès partagé
Créer et utiliser une signature d’accès partagé
Définir une stratégie d’accès stockée
Get Container ACL
Autoriser les demandes à Stockage Azure
Codes d’état et d’erreur
Codes d’erreur du service Blob