Set Table ACL
L’opération Set Table ACL
définit les stratégies d’accès stockées pour la table qui peuvent être utilisées avec des signatures d’accès partagé. Pour plus d’informations, consultez Mise en place d’une stratégie d’accès stockée.
Notes
L'opération Set Table ACL
est disponible dans la version du 12/02/2012 et les versions ultérieures.
Notes
Une liste de contrôle d’accès (ACL) est une liste d’entrées de contrôle d’accès (AES). Chaque ACE dans une ACL identifie un tiers de confiance et spécifie les droits d'accès autorisés, refusés ou audités pour ce tiers de confiance. Pour plus d’informations, consultez Listes de contrôle d’accès.
Requête
Vous pouvez construire la Set Table ACL
requête comme suit. Nous recommandons HTTPS. Remplacez myaccount par le nom de votre compte de stockage.
Méthode | URI de demande | Version HTTP |
---|---|---|
PUT |
https://myaccount.table.core.windows.net/mytable?comp=acl |
HTTP/1.1 |
URI de service de stockage émulé
Lorsque vous effectuez une requête auprès du service de stockage émulé, spécifiez le nom d’hôte de l’émulateur et le port Stockage Table Azure en tant que 127.0.0.1:10002
. Ajoutez ensuite le nom du compte de stockage émulé.
Méthode | URI de demande | Version HTTP |
---|---|---|
PUT |
http://127.0.0.1:10002/devstoreaccount1/mytable?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. Exprimé en secondes. Pour plus d’informations, consultez Définir des délais d’expiration pour les opérations de stockage table. |
En-têtes de requête
Le tableau suivant décrit les en-têtes de requête obligatoires et facultatifs :
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 |
Optionnel. 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-client-request-id |
Optionnel. 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 d’Storage Analytics 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 reçues par le serveur. |
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 Table ACL
.
L’élément SignedIdentifier
inclut l’identificateur unique, comme spécifié dans l’élément Id
.
SignedIdentifier
inclut également les détails de la stratégie d’accès, comme spécifié 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 les suivants :
YYYY-MM-DD
YYYY-MM-DDThh:mmTZD
YYYY-MM-DDThh:mm:ssTZD
YYYY-MM-DDThh:mm:ss.ffffffTZD
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 ffffff
est la représentation des millisecondes à six chiffres. L’indicateur T
d’heure sépare les parties date et heure de la chaîne. L’indicateur 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.table.core.windows.net/mytable?comp=acl HTTP/1.1
Request Headers:
x-ms-version: 2013-08-15
x-ms-date: Mon, 25 Nov 2013 00:42:49 GMT
Authorization: SharedKey myaccount:V47F2tYLS29MmHPhiR8FyiCny9zO5De3kVSF0RYQHmo=
Request Body:
<?xml version="1.0" encoding="utf-8"?>
<SignedIdentifiers>
<SignedIdentifier>
<Id>MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=</Id>
<AccessPolicy>
<Start>2013-11-26T08:49:37.0000000Z</Start>
<Expiry>2013-11-27T08:49:37.0000000Z</Expiry>
<Permission>raud</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 renvoie le code d'état 204 (Aucun contenu).
Pour plus d’informations sur les codes status, consultez État et codes 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 également 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 |
---|---|
x-ms-request-id |
Identifie de manière unique la demande qui a été effectuée. Vous pouvez également l’utiliser pour résoudre les problèmes liés à 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 stockage table 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 qui indique l’heure à laquelle le service a envoyé la réponse. |
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 est au maximum 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, cet en-tête ne sera pas présent dans la réponse. |
Exemple de réponse
Response Status:
HTTP/1.1 204 No Content
Response Headers:
Transfer-Encoding: chunked
Date: Mon, 25 Nov 2013 22:42:55 GMT
x-ms-version: 2013-08-15
Server: Windows-Azure-Table/1.0 Microsoft-HTTPAPI/2.0
Autorisation
Seul le propriétaire du compte peut appeler cette opération.
Notes
Seul le propriétaire du compte peut accéder aux ressources d’une table particulière, sauf si le propriétaire a émis une signature d’accès partagé pour une ressource dans la table.
Quand vous définissez des autorisations pour une table, les autorisations existantes sont remplacées. Pour mettre à jour les autorisations de la table, appelez Get Table ACL pour extraire toutes les stratégies d’accès associées à la table. Modifiez la stratégie d’accès que vous souhaitez modifier, puis appelez Set Table ACL
avec l’ensemble complet de données pour effectuer la mise à jour.
Établissement de stratégies d’accès stockées
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 ressource de partage ou de fichier, vous pouvez :
- Spécifiez tous ces paramètres dans la stratégie d’accès stockée et omettez-les de l’URL de la signature d’accès partagé. Cela vous permet de modifier le comportement de la signature associée ou de la révoquer à tout moment.
- Spécifiez un ou plusieurs paramètres de stratégie d’accès dans la stratégie d’accès stockée et spécifiez les autres paramètres sur l’URL.
- Spécifiez 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, mais pas pour modifier son comportement.
Pour plus d’informations sur l’établissement de stratégies d’accès, consultez Définir 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 les champs obligatoires sont manquants, la demande échoue. De même, si un champ est spécifié dans l'URL de la signature d'accès partagé et dans la stratégie d'accès stockée, la demande échoue avec le code d'état 400 (Requête incorrecte). Pour plus d’informations sur les champs qui composent une signature d’accès partagé, consultez Créer une sape de service.
Vous pouvez définir un maximum de cinq stratégies d’accès distinctes pour une table à 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).
Notes
Lorsque vous établissez une stratégie d’accès stockée sur une table, elle peut prendre jusqu’à 30 secondes. Pendant cet intervalle, une signature d’accès partagé associée à la stratégie d’accès stockée échoue avec status code 403 (Interdit), jusqu’à ce que la stratégie d’accès soit active.
Voir aussi
Définir une stratégie d’accès stockée
Créer et utiliser une signature d’accès partagé
Déléguer l’accès avec une signature d’accès partagé
Get Table ACL
Autoriser les demandes dans le Stockage Azure
Codes d’état et d’erreur