Partager via

Définition de liste de contrôle d’accès aux files d'attente

  • Article

L’opération Set Queue ACL définit des stratégies d’accès stockées pour la file d’attente qui peuvent être utilisées avec une signature d’accès partagé (SAP). Pour plus d’informations, consultez Mise en place d’une stratégie d’accès stockée.

Notes

L'opération Set Queue ACL est disponible dans la version du 12/02/2012 et les versions ultérieures.

Requête

Vous pouvez construire la Set Queue ACL requête comme suit. 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.queue.core.windows.net/myqueue?comp=acl HTTP/1.1

Demande de service de stockage émulée

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 du service file d’attente comme 127.0.0.1:10001, suivi du nom du compte de stockage émulé :

Méthode URI de demande Version HTTP
PUT http://127.0.0.1:10001/devstoreaccount1/myqueue?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 file d’attente.

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 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 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. Pour plus d’informations, consultez Surveiller le stockage File d’attente Azure.

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 Queue 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.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. Un indicateur d’heure T sépare les parties de date et d’heure de la chaîne, et un 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.queue.core.windows.net/myqueue?comp=acl HTTP/1.1  
  
Request Headers:  
x-ms-version: 2012-02-12  
x-ms-date: Sun, 25 Sep 2011 00:42:49 GMT  
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>raup</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 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
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 file d’attente utilisée pour exécuter la demande. Cet en-tête est retourné pour les demandes effectuées sur la version 2009-09-19 et 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 Cet en-tête 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 204 No Content  
  
Response Headers:  
Transfer-Encoding: chunked  
Date: Sun, 25 Sep 2011 22:42:55 GMT  
x-ms-version: 2012-02-12  
Server: Windows-Azure-Queue/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 file d’attente particulière, sauf si le propriétaire a émis une signature d’accès partagé pour une ressource dans la file d’attente.

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

Établir des 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 file d’attente, 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 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 des champs obligatoires sont manquants, la demande échoue. De même, si un champ est spécifié à la fois 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 une file d’attente unique à 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).

Lorsque vous établissez une stratégie d’accès stockée sur une file d’attente, l’application 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
Get Queue ACL
Autoriser les demandes à Stockage Azure
Codes d’état et d’erreur