VENTES: 1-800-867-1389

Contrôle de version pour les services de stockage Azure

Mis à jour: mai 2014

Plusieurs versions des services de stockage Microsoft Azure sont prises en charge. Lorsque vous effectuez une demande aux services de stockage Azure, vous devez spécifier la version que vous souhaitez utiliser pour cette opération, sauf s'il s'agit d'une demande anonyme.

Dans la mesure du possible, utilisez la version actuelle (2014-02-14) des services de stockage Azure. Pour obtenir la liste de toutes les autres versions prises en charge ainsi que des informations sur l'utilisation de chaque version, consultez Azure Storage Services Versions 2013-08-15 and Earlier.

La version du 14.02.14 comprend les modifications suivantes :

  • Avec le nouveau service de Fichier Microsoft Azure, les machines virtuelles s'exécutant dans un centre de données Microsoft Azure peuvent monter un système de fichiers partagés via le protocole SMB et y accéder à l'aide des API de fichier Windows standard. Ce système de fichiers peut être attaché à plusieurs machines virtuelles (ou rôles exécutés dans un service cloud) à la fois, ce qui vous permet de partager facilement des données persistantes entre les différents rôles et instances. Similaire à l'API du service BLOB, l'API REST du service de Fichier offre un autre moyen d'accéder aux fichiers en plus des API de fichier Windows. Pour plus d'informations, consultez File Service REST API.

  • Les signatures d'accès partagé prennent maintenant en charge le paramètre api-version, en plus du paramètre SignedVersion (sv). Ces deux paramètres contrôlent les versions des services de stockage qui sont utilisées pour authentifier et autoriser une demande, et pour exécuter l'opération de l'API. Pour plus d'informations, consultez la section Demandes authentifiées avec une signature d'accès partagé, ci-dessous.

La façon dont vous devez spécifier la version des services de stockage à utiliser lors d'une demande dépend du mode d'authentification de cette demande. Les sections suivantes décrivent les différentes options d'authentification et les méthodes correspondantes pour spécifier la version des services :

  1. Demandes utilisant Shared Key ou Shared Key Lite Pour authentifier une demande avec Shared Key ou Shared Key Lite, spécifiez l'en-tête x-ms-version dans la demande. S'il s'agit d'un service BLOB, vous pouvez spécifier la version par défaut à utiliser pour toutes les demandes en appelant Set Blob Service Properties.

  2. Demandes utilisant une signature d'accès partagé (SAS) Vous pouvez spécifier deux options de contrôle de version pour une signature d'accès partagé. S'il est spécifié, l'en-tête facultatif api-version indique quelle version des services utiliser pour exécuter l'opération de l'API. Le paramètre SignedVersion (sv) spécifie quelle version des services utiliser pour authentifier et autoriser la demande effectuée avec une signature d'accès partagé (SAS). Si l'en-tête api-version n'est pas spécifié, la valeur du paramètre SignedVersion (sv) indique également la version à utiliser pour exécuter l'opération de l'API.

  3. Demandes utilisant l'accès anonyme Dans le cas d'une demande anonyme au service BLOB, aucune version n'est spécifiée. Le choix de la version utilisée est déterminé par certaines règles (voir plus bas).

Pour authentifier une demande avec Shared Key ou Shared Key Lite, spécifiez l'en-tête x-ms-version dans la demande. La valeur d'en-tête de demande x-ms-version doit être spécifiée au format AAAA-MM-JJ. Par exemple :

Request Headers:
x-ms-version: 2014-02-14

Les demandes avec authentification Shared Key ou Shared Key Lite sont évaluées selon les règles suivantes pour déterminer la version à utiliser pour les traiter.

  • Si une demande a un en-tête valide x-ms-version, le service de stockage utilise la version spécifiée. Toutes les demandes aux services de Table et de File d'attente qui n'utilisent pas une signature d'accès partagé doivent spécifier un en-tête x-ms-version. Toutes les demandes au service BLOB qui n'utilisent pas de signature d'accès partagé doivent spécifier un en-tête x-ms-version, sauf si la version par défaut a été définie, comme décrit ci-dessous.

  • Si une demande au service BLOB ne contient pas d'en-tête x-ms-version, mais que le propriétaire du compte a défini une version par défaut avec Set Blob Service Properties, la version par défaut spécifiée est utilisée pour la demande.

Une signature d'accès partagé (SAS) générée avec la version 2014-02-14 prend en charge deux options de contrôle de version :

  • Le paramètre de requête api-version définit la version du protocole REST à utiliser pour traiter une demande effectuée avec une signature d'accès partagé (SAS).

  • Le paramètre de requête SignedVersion (sv) définit la version de la signature d'accès partagé à utiliser pour l'authentification et l'autorisation.

Le paramètre de requête SignedVersion est utilisé pour l'authentification et l'autorisation d'une demande effectuée avec une signature d'accès partagé. Les paramètres d'authentification et d'autorisation (tels que si, sr, sp, sig, st, se, tn, spk, srk, epk et erk) sont tous interprétés selon la version 2014-02-14.

Les paramètres de protocole REST (tels que rscc, rscd, rsce, rscl et rsct) sont appliqués avec la version spécifiée dans l'en-tête de paramètre api-version. Si l'en-tête api-version n'est pas spécifié, la version des services utilisée est celle indiquée par le paramètre SignedVersion.

Notez que le paramètre api-version ne fait pas partie de la chaîne de signature pour l'authentification décrite dans Construction de l'URI de signature d'accès partagé.

Le tableau suivant décrit le schéma de contrôle de version que le service utilise pour l'authentification et l'autorisation des demandes, ainsi que pour l'appel du protocole REST lorsque le paramètre SignedVersion spécifie la version 2014-02-14 ou une version ultérieure.

 

Valeur du paramètre api-version Version utilisée pour l'authentification et l'autorisation Version utilisée pour le comportement de protocole

Non spécifiée

Version spécifiée dans le paramètre sv

Version spécifiée dans le paramètre sv

N'importe quelle version valide des services de stockage, au format XXXX-XX-XX

Version spécifiée dans le paramètre sv

N'importe quelle version valide des services de stockage, au format XXXX-XX-XX

Exemple 1

Dans cet exemple, la demande appelle List Blobs avec sv=2014-02-14, sans spécifier de paramètre api-version.

https://myaccount.blob.core.windows.net/mycontainer?restype=container&comp=list&sv=2014-02-14&si=readpolicy&sig=a39 %2BYozJhGp6miujGymjRpN8tsrQfLo9Z3i8IRyIpnQ%3d

Dans ce cas, le service utilise la version 2014-02-14 à la fois pour authentifier et autoriser la demande et pour exécuter l'opération.

Exemple 2

Dans cet exemple, la demande appelle List Blobs avec sv=2014-02-14, en spécifiant le paramètre api-version.

https://myaccount.blob.core.windows.net/mycontainer?restype=container&comp=list&sv=2014-02-14&si=readpolicy&sig=a39 %2BYozJhGp6miujGymjRpN8tsrQfLo9Z3i8IRyIpnQ%3d&api-version=2012-02-12

Dans ce cas, le service utilise la version 2014-02-14 pour authentifier et autoriser la demande, mais il utilise la version 2012-02-12 pour exécuter l'opération.

noteRemarque
La bibliothèque cliente de stockage pour .NET définit toujours la version du protocole REST (avec le paramètre api-version) en fonction de sa version de base.

Lorsqu'une demande au service BLOB ne spécifie pas l'en-tête x-ms-version, et qu'aucune version par défaut n'a été définie pour le service avec Set Blob Service Properties, la version du service BLOB la plus récente est utilisée pour traiter la demande. Toutefois, si le conteneur a été rendu public à l'aide d'une opération Set Container ACL effectuée avec la version 2009-09-19 ou une version ultérieure, la demande sera traitée en utilisant la version 2009-09-19.

Voir aussi

Cela vous a-t-il été utile ?
(1500 caractères restants)
Merci pour vos suggestions.
Afficher:
© 2014 Microsoft