VENTES: 1-800-867-1389

Prise en charge du service Partage des ressources cross-origine (CORS) pour les services de stockage Azure

Mis à jour: novembre 2013

Depuis la version du 15/08/2013, les services de stockage Windows Azure prennent en charge le Partage de ressources cross-origine (CORS) pour les services BLOB, de Table et de File d'attente. 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. Les navigateurs Web implémentent une restriction de sécurité appelée stratégie de même origine qui empêche une page Web d'appeler des API d'un autre domaine ; CORS constitue un moyen sûr pour autoriser un domaine (le domaine d'origine) à appeler des API d'un autre domaine. Pour plus d'informations sur CORS, consultez la spécification CORS.

Définissez des règles CORS individuellement pour chaque service de stockage, en appelant Set Blob Service Properties, Set Queue Service Properties et Set Table Service Properties. 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.

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 obligatoire, sauf si la méthode de demande est une méthode simple, ce qui signifie 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 nécessaires (les en-têtes Origin et Access-Control-Request-Method), le service répond avec le code d'état 400 (Demande incorrecte).

Notez qu'une demande préliminaire est évaluée par rapport au service (Blob, de File d'attente et de Table) et non pas par rapport à 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 retourné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 retournés.

Les règles CORS sont définies au niveau du service. Par conséquent, vous devez activer ou désactiver les CORS pour chaque service (Blob, de File d'attente et de 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ées à l'aide de la version du 15/08/2013 ou des versions ultérieures, et ajouter des règles CORS aux propriétés de service. Pour plus d'informations sur l'activation ou la désactivation de règles CORS pour un service et leur définition, consultez Set Blob Service Properties, Set Table Service Properties et Set Queue Service Properties.

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 peuvent effectuer des demandes dans le 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és. 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, il est indiqué au navigateur 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 Windows Azure prennent en charge la spécification d'en-têtes préfixés pour les éléments AllowedHeaders et ExposedHeaders. Pour autoriser une catégorie d'en-têtes, spécifiez un préfixe commun à cette catégorie. Par exemple, le fait de spécifier x-ms-meta* comme en-tête préfixé établit une règle qui correspond à tous les en-têtes commençant 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, Table et File d'attente).

  • La taille maximale de tous les paramètres de règles CORS dans la requête, à 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 :

    • Des en-têtes littéraux, où le nom précis d'en-tête est spécifié, tel que x-ms-meta-processed. Au plus 64 en-têtes littéraux peuvent être spécifiés sur la requête.

    • Des 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é. Au plus deux en-têtes préfixés peuvent être spécifiés sur la requête.

  • Les méthodes (ou verbes HTTP) spécifiées dans l'élément AllowedMethods doivent 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.

Lorsqu'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 vérifié par rapport aux domaines répertoriés pour l'élément AllowedOrigins. 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 l'élément AllowedMethods. 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. Pour que la demande réussisse, tous les en-têtes spécifiés dans la demande sont vérifiés par rapport aux en-têtes répertoriés dans l'élément AllowedHeaders. 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. Pour plus d'informations sur la construction de la requête, consultez Set Blob Service Properties, Set Queue Service Properties et Set Table Service Properties.

<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

Réussite

GET

http://www.contoso.com

x-ms-blob-content-type

Deuxième règle

Réussite

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 ; donc, la demande 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, l'en-tête x-ms-client-request-id n'est pas autorisé par la deuxième règle, donc la demande échoue, en dépit du fait que la sémantique de la troisième règle lui aurait permis de réussir.

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.

L'en-tête Vary est un en-tête HTTP/1.1 standard composé d'un ensemble de champs d'en-tête de demande qui indiquent au navigateur ou à l'agent utilisateur les critères qui ont été sélectionnés par le serveur pour traiter la demande. L'en-tête Vary est principalement utilisé pour la mise en cache par les proxys, les navigateurs et les réseaux de distribution de contenu, qui s'en servent pour déterminer comment la réponse doit être mise en cache. Pour plus d'informations, consultez la spécification de l'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. Lorsqu'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 Windows Azure affecte à l'en-tête Vary la valeur Origin pour indiquer à l'agent utilisateur d'envoyer la demande CORS suivante au service lorsque le domaine demandeur diffère de l'origine mise en cache.

Le stockage Windows Azure affecte à l'en-tête Vary la valeur Origin 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 qu'en ce qui concerne les demandes à l'aide de méthodes autres que GET/HEAD, les services de stockage ne définissent pas l'en-tête Vary, car les réponses à ces méthodes ne sont pas mises en cache par les agents utilisateurs.

Le tableau suivant indique comment le stockage Windows 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 règles CORS pour un des services de stockage de votre compte (en appelant Set Blob Service Properties, Set Queue Service Properties ou Set Table Service Properties.) Pour réduire les frais, envisagez d'affecter une valeur plus élevée à l'élément MaxAgeInSeconds dans vos règles CORS, de façon à ce que l'agent utilisateur mette en cache la demande.

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

Voir aussi

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