Cet article a fait l’objet d’une traduction automatique. Pour afficher l’article en anglais, activez la case d’option Anglais. Vous pouvez également afficher le texte anglais dans une fenêtre contextuelle en faisant glisser le pointeur de la souris sur le texte traduit.
Traduction
Anglais

Prise en charge (CORS) pour les Services de stockage Azure le partage des ressources Cross-Origin.

 

Depuis la version du 15/08/2013, les services de stockage Azure prennent en charge le Partage de ressources cross-origine (CORS) pour les services BLOB, de Table et de File d'attente. Le service de fichiers prend en charge la version 2015-02-21 à compter de CORS.

CORS est une fonctionnalité HTTP qui permet à une application Web exécutée dans un seul domaine d'accéder aux ressources d'un autre domaine. Navigateurs Web implémentent une restriction de sécurité connu sous le nom stratégie de même origine qui empêche une page web d'appeler des API dans un autre domaine. CORS constitue un moyen sécurisé pour autoriser un domaine (le domaine d'origine) appeler des API dans un autre domaine. Voir la spécification CORS pour plus d'informations sur CORS.

Vous pouvez définir les règles CORS individuellement pour chacun des services de stockage, en appelant Définition des propriétés du service Blob, Définition des propriétés du service Fichier, Définition des propriétés du service de File d'attente, et Définition des propriétés du service de Table. Une fois que vous avez défini les règles CORS du service, une demande authentifiée effectuée dans le service à partir d'un autre domaine est évaluée pour déterminer si elle est autorisée conformément aux règles que vous avez spécifiées.

System_CAPS_noteRemarque

Notez que les règles CORS ne sont pas un mécanisme d'authentification. Toute demande adressée à une ressource de stockage lorsque des règles CORS sont activées doit avoir une signature d'authentification appropriée, ou doit être effectuée sur une ressource publique.

Une demande CORS d'un domaine d'origine peut comprendre deux demandes distinctes :

  • Une demande préliminaire, qui interroge les restrictions CORS imposées par le service. La demande préliminaire est nécessaire sauf si la méthode de requête est un méthode simple, ce qui signifie que GET, HEAD ou POST.

  • La demande réelle, effectuée sur la ressource souhaitée.

La demande préliminaire interroge les restrictions CORS qui ont été créées pour le service de stockage par le propriétaire du compte. Le navigateur Web (ou tout autre agent utilisateur) envoie une demande OPTIONS qui comprend les en-têtes de demande, la méthode et le domaine d'origine. Le service de stockage évalue l'opération selon un ensemble préconfiguré de règles CORS qui indiquent les domaines d'origine, les méthodes de demande et les en-têtes de demande qui peuvent être spécifiés dans une demande réelle sur une ressource de stockage.

Si des règles CORS sont activées pour le service et que l'une d'elles correspond à la demande préliminaire, le service répond avec le code d'état 200 (OK) et inclut les en-têtes Access-Control dans la réponse.

Si les règles CORS ne sont pas activées pour le service ou aucune règle CORS ne correspond à la demande préliminaire, le service répond avec le code d'état 403 (Interdit).

Si la demande OPTIONS ne contient pas les en-têtes CORS (en-têtes Origin et Access-Control-Request-Method) nécessaires, le service répond avec le code d'état 400 (demande incorrecte).

Notez qu'une demande préliminaire est évaluée sur le service (Blob, fichier, file d'attente ou Table) et non sur la ressource demandée. Le propriétaire du compte doit avoir activé des CORS dans le cadre des propriétés du service de compte pour la réussite de la demande.

Une fois la demande préliminaire acceptée et la réponse renvoyée, le navigateur distribue la demande réelle sur la ressource de stockage. Le navigateur refuse la demande réelle immédiatement, si la demande préliminaire est rejetée.

La demande réelle est traitée comme une demande normale dans le service de stockage. La présence de l'en-tête Origin indique que la demande est une demande CORS et le service recherche les règles CORS correspondantes. Si une correspondance est trouvée, les en-têtes Access-Control sont ajoutés à la réponse et renvoyés au client. Si la correspondance est introuvable, les en-têtes Access-Control CORS ne sont pas renvoyés.

Les règles CORS sont définies au niveau du service, vous devez activer ou désactiver les CORS pour chaque service (Blob, fichier, file d'attente et Table) séparément. Par défaut, les règles CORS sont désactivées pour tous les services. Pour activer les CORS, vous devez définir les propriétés de service approprié à l'aide de la version 2013-08-15 ou version ultérieure pour la version 2015-02-21 ou services Blob, Table et file d'attente ou pour le service de fichiers. Activer les CORS en ajoutant des règles CORS aux propriétés de service. Pour plus d'informations sur la façon d'activer ou désactiver les CORS pour un service et comment définir des règles CORS, reportez-vous à Définition des propriétés du service Blob, Définition des propriétés du service Fichier, Définition des propriétés du service de Table, et Définition des propriétés du service de File d'attente.

Voici un exemple d'une seule règle CORS, spécifiée via une opération Set Service Properties :

<Cors> <CorsRule> <AllowedOrigins>http://www.contoso.com, http://www.fabrikam.com</AllowedOrigins> <AllowedMethods>PUT,GET</AllowedMethods> <AllowedHeaders>x-ms-meta-data*,x-ms-meta-target*,x-ms-meta-abc</AllowedHeaders> <ExposedHeaders>x-ms-meta-*</ExposedHeaders> <MaxAgeInSeconds>200</MaxAgeInSeconds> </CorsRule> <Cors>

Chaque élément inclus dans la règle CORS est décrit ci-dessous :

  • AllowedOrigins: domaines d'origine qui sont autorisés à effectuer une demande dans le service de stockage via des règles CORS. Le domaine d'origine est le domaine d'où provient la demande. Notez que l'origine doit être une correspondance sensible à la casse exacte avec l'origine, que l'âge d'utilisateur envoie au service. Vous pouvez également utiliser le caractère générique « * » pour permettre à tous les domaines d'origine d'effectuer des demandes via les règles CORS. Dans l'exemple ci-dessus, les domaines http://www.contoso.com et http://www.fabrikam.com peut envoyer des demandes au service à l'aide de CORS.

  • AllowedMethods: méthodes (verbes de requête HTTP) que le domaine d'origine peut utiliser pour une demande CORS. Dans l'exemple ci-dessus, seules les demandes PUT et GET sont autorisées.

  • AllowedHeaders: en-têtes de demande que le domaine d'origine peut spécifier dans la demande CORS. Dans l'exemple ci-dessus, tous les en-têtes de métadonnées commençant par x-ms-meta-data, x-ms-meta-target, et x-ms-meta-abc sont autorisées. Notez que le caractère générique « * » indique que les en-têtes commençant par le préfixe spécifié sont autorisés.

  • ExposedHeaders: en-têtes de réponse qui peuvent être envoyés dans la réponse à la demande CORS, et exposés par le navigateur à l'émetteur de la demande. Dans l'exemple ci-dessus, le navigateur est tenue d'exposer les en-têtes commençant par x-ms-meta.

  • MaxAgeInSeconds: durée maximale pendant laquelle un navigateur doit mettre en cache la demande OPTIONS préliminaire.

Les services de stockage Azure prennent en charge la spécification d'en-têtes préfixés à la fois pour le AllowedHeaders et ExposedHeaders éléments. Pour autoriser une catégorie d'en-têtes, spécifiez un préfixe commun à cette catégorie. Par exemple, la spécification x-ms-meta* comme en-tête préfixé établit une règle qui correspond à tous les en-têtes qui commencent par x-ms-meta.

Les limitations suivantes s'appliquent aux règles CORS :

  • Vous pouvez spécifier jusqu'à cinq règles CORS par service de stockage (Blob, de fichier, Table et file d'attente).

  • La taille maximale de tous les paramètres de règles CORS dans la demande, à l'exception des balises XML, ne doit pas dépasser 2 Ko.

  • La longueur d'un en-tête autorisé, de l'en-tête exposé, ou de l'origine autorisée ne doit pas dépasser 256 caractères.

  • Les en-têtes autorisés et les en-têtes exposés peuvent être :

    • En-têtes littéraux, où le nom précis d'en-tête est spécifié, tel que x-ms-meta-processed. Il ne peut pas y avoir plus de 64 en-têtes littéraux spécifiés sur la demande.

    • En-têtes préfixés, où un préfixe de l'en-tête est spécifié, tel que x-ms-meta-data*. Le fait de spécifier un préfixe de cette façon autorise ou expose les en-têtes qui commencent par le préfixe donné. Il ne peut pas y avoir plus de deux en-têtes préfixés spécifiés sur la demande.

  • Les méthodes (ou les verbes HTTP) spécifié dans le AllowedMethods élément doit respecter les méthodes prises en charge par les API de service de stockage Windows Azure. Les méthodes prises en charge sont DELETE, GET, HEAD, MERGE, POST, OPTIONS et PUT.

Quand un service de stockage reçoit une demande préliminaire ou réelle, il évalue cette demande en fonction des règles CORS que vous avez créées pour le service via l'opération Set Service Properties. Les règles CORS sont évaluées dans l'ordre dans lequel elles ont été définies dans le corps de la demande de l'opération Set Service Properties.

Les règles CORS sont évaluées comme suit :

  1. Tout d'abord, le domaine d'origine de la demande est comparé aux domaines répertoriés pour le AllowedOrigins élément. Si le domaine d'origine figure dans la liste, ou tous les domaines sont autorisés avec le caractère générique « * », alors l'évaluation des règles continue. Si le domaine d'origine n'est pas inclus, la demande échoue.

  2. Ensuite, la méthode (ou le verbe HTTP) de la demande est comparée aux méthodes répertoriées dans le AllowedMethods élément. Si la méthode figure dans la liste, l'évaluation des règles continue ; sinon, la demande échoue.

  3. Si la demande correspond à une règle dans son domaine d'origine et sa méthode, cette règle est sélectionnée pour traiter la demande et aucune autre règle n'est évaluée. Toutefois, avant que la demande réussisse, tous les en-têtes spécifiés dans la demande sont vérifiées aux en-têtes répertoriés dans le AllowedHeaders élément. Si les en-têtes envoyés ne correspondent pas aux en-têtes autorisés, la demande échoue.

Étant donné que les règles sont traitées dans l'ordre dans lequel elles sont indiquées dans le corps de la demande, il est recommandé de spécifier les règles les plus restrictives en ce qui concerne les origines en premier dans la liste, afin qu'elles soient évaluées en premier. Spécifiez les règles les moins restrictives (par exemple, une règle pour autoriser toutes les origines) à la fin de la liste.

L'exemple suivant illustre un corps de demande partiel d'opération afin de définir des règles CORS pour les services de stockage. Consultez Définition des propriétés du service Blob, Définition des propriétés du service Fichier, Définition des propriétés du service de File d'attente, et Définition des propriétés du service de Table Pour plus d'informations sur la construction de la demande.

<Cors> <CorsRule> <AllowedOrigins>http://www.contoso.com</AllowedOrigins> <AllowedMethods>PUT,HEAD</AllowedMethods> <MaxAgeInSeconds>5</MaxAgeInSeconds> <ExposedHeaders>x-ms-*</ExposedHeaders> <AllowedHeaders>x-ms-blob-content-type, x-ms-blob-content-disposition</AllowedHeaders> </CorsRule> <CorsRule> <AllowedOrigins>*</AllowedOrigins> <AllowedMethods>PUT,GET</AllowedMethods> <MaxAgeInSeconds>5</MaxAgeInSeconds> <ExposedHeaders>x-ms-*</ExposedHeaders> <AllowedHeaders>x-ms-blob-content-type, x-ms-blob-content-disposition</AllowedHeaders> </CorsRule> <CorsRule> <AllowedOrigins>http://www.contoso.com</AllowedOrigins> <AllowedMethods>GET</AllowedMethods> <MaxAgeInSeconds>5</MaxAgeInSeconds> <ExposedHeaders>x-ms-*</ExposedHeaders> <AllowedHeaders>x-ms-client-request-id</AllowedHeaders> </CorsRule> </Cors>

Ensuite, tenez compte des demandes CORS suivantes :

Request

Response

Method

Origin

Request headers

Rule Match

Result

PUT

http://www.contoso.com

x-ms-blob-content-type

Première règle

Success

get

http://www.contoso.com

x-ms-blob-content-type

Deuxième règle

Success

get

http://www.contoso.com

x-ms-client-request-id

Deuxième règle

Échec

La première demande correspond à la première règle (le domaine d'origine correspond aux origines autorisées, la méthode correspond aux méthodes autorisées et l'en-tête correspond aux en-têtes autorisés), de sorte qu'elle réussit.

La deuxième demande ne correspond pas à la première règle, car la méthode ne correspond pas aux méthodes autorisées. Toutefois, elle correspond à la deuxième règle, et réussit.

La troisième demande correspond à la deuxième règle en ce qui concerne le domaine d'origine et la méthode, donc aucune autre règle n'est évaluée. Toutefois, le x-ms-client-request-id en-tête n'est pas autorisée par la deuxième règle, la demande échoue, malgré le fait que la sémantique de la troisième règle lui aurait permis de réussir.

System_CAPS_noteRemarque

Bien que cet exemple illustre une règle moins restrictive avant une règle plus restrictive, il est généralement recommandé de répertorier les règles les plus restrictives en premier.

Le Vary en-tête est un en-tête HTTP/1.1 standard composé d'un ensemble de champs d'en-tête de demande qui indiquent l'agent utilisateur ou du navigateur sur les critères qui ont été sélectionnés par le serveur pour traiter la demande. Le Vary en-tête est principalement utilisé pour la mise en cache par les proxys, les navigateurs et les CDN, ce qui permet de déterminer comment la réponse doit être mise en cache. Pour plus d'informations, consultez la spécification de la en-tête Vary.

Lorsque le navigateur ou un autre agent utilisateur met en cache la réponse d'une demande CORS, le domaine d'origine est mis en cache comme origine autorisée. Quand un deuxième domaine émet la même demande de ressource de stockage pendant que le cache est actif, l'agent utilisateur récupère le domaine d'origine mis en cache. Le deuxième domaine ne correspond pas au domaine mis en cache, la demande échoue alors qu'elle devrait réussir en d'autres circonstances. Dans certains cas, le stockage Azure affecte le Vary en-tête origine pour demander à l'agent utilisateur pour envoyer la demande CORS suivante au service lorsque le domaine demandeur diffère de l'origine de la mise en cache.

Stockage Azure affecte le Vary en-tête origine pour les demandes GET/HEAD réelles dans les cas suivants :

  • Lorsque l'origine de la demande correspond exactement à l'origine autorisée définie par une règle CORS. Pour être une correspondance exacte, la règle CORS ne doit pas inclure de caractère générique « * ».

  • Il n'y a aucune règle correspondant à l'origine de la demande, mais les règles CORS sont activées pour le service de stockage.

Si une demande GET/HEAD correspond à une règle CORS qui autorise toutes les origines, la réponse indique que toutes les origines sont autorisées, et le cache de l'agent utilisateur autorise les demandes suivantes à partir de n'importe quel domaine d'origine pendant que le cache est actif.

Notez que pour les demandes à l'aide de méthodes autres que GET/HEAD, les services de stockage ne définira pas la Vary en-tête, étant donné que les réponses à ces méthodes ne sont pas mises en cache par les agents utilisateurs.

Le tableau suivant indique comment le stockage Azure répond aux demandes GET/HEAD en fonction des cas mentionnés précédemment :

Demande

Paramètre de compte et résultat d'évaluation de règle

Réponse

En-tête d'origine présent dans la demande

Règle(s) CORS spécifiée(s) pour ce service

Règle de correspondance existante qui autorise toutes les origines (*)

Règle de correspondance existante pour la correspondance exacte d'origine

La réponse inclut l'en-tête Vary avec la valeur Origin

La réponse inclut l'en-tête Access-Control-Allowed-Origin : « * »

La réponse inclut l'en-tête Access-Control-Exposed-Headers

Non

Non

Non

Non

Non

Non

Non

Non

Oui

Non

Non

Oui

Non

Non

Non

Oui

Oui

Non

Non

Oui

Oui

Oui

Non

Non

Non

Non

Non

Non

Oui

Oui

Non

Oui

Oui

Non

Oui

Oui

Oui

Non

Non

Oui

Non

Non

Oui

Oui

Oui

Non

Non

Oui

Oui

Les demandes préliminaires ayant réussi sont facturées si vous avez activé des CORS pour les services de stockage pour votre compte (en appelant Définition des propriétés du service Blob, Définition des propriétés du service de File d'attente, Définition des propriétés du service Fichier, ou Définition des propriétés du service de Table). Pour réduire les frais, envisagez d'affecter le MaxAgeInSeconds élément dans votre CORS des règles pour une valeur élevée afin que l'agent utilisateur met en cache la demande.

Les demandes préliminaires infructueuses ne sont pas facturées.

Afficher: