From 3518481e9190f19bbf81741704f45cb3c1761758 Mon Sep 17 00:00:00 2001 From: SphinxKnight Date: Fri, 17 Sep 2021 20:08:55 +0200 Subject: Prepare HTTP section for Markdown conversion (#2453) * Remove summary classes * Remove hidden blocks * Remove id when not in headings * Remove notranslate * remove unecessary ltr dir * Remove spans from automatic translation tool copy/paste * Remove unhandled pe brush for plain text * make consistent notes * make consistent warning + rm rfc class * fix one-offs and images + spans * fix dls and subsequent oneoff errors * fix sups --- .../corsalloworiginnotmatchingorigin/index.html | 6 +- .../http/cors/errors/corsdidnotsucceed/index.html | 2 +- .../cors/errors/corsmissingalloworigin/index.html | 12 +-- files/fr/web/http/cors/errors/index.html | 10 +-- files/fr/web/http/cors/index.html | 100 ++++++++++----------- 5 files changed, 65 insertions(+), 65 deletions(-) (limited to 'files/fr/web/http/cors') diff --git a/files/fr/web/http/cors/errors/corsalloworiginnotmatchingorigin/index.html b/files/fr/web/http/cors/errors/corsalloworiginnotmatchingorigin/index.html index 0f178e49eb..e113a3438b 100644 --- a/files/fr/web/http/cors/errors/corsalloworiginnotmatchingorigin/index.html +++ b/files/fr/web/http/cors/errors/corsalloworiginnotmatchingorigin/index.html @@ -16,7 +16,7 @@ original_slug: Web/HTTP/CORS/Errors/CORSAllowOriginNeCorrespondPas

Symptomes

-
Raison : l’en-tête CORS « Access-Control-Allow-Origin » ne correspond pas à « xyz »
+
Raison : l’en-tête CORS « Access-Control-Allow-Origin » ne correspond pas à « xyz »

Quel est le problème ?

@@ -28,11 +28,11 @@ original_slug: Web/HTTP/CORS/Errors/CORSAllowOriginNeCorrespondPas

Par exemple, dans Apache, ajoutez une ligne comme celle qui suit à la configuration du serveur (dans la section appropriée <Directory>, <Location>, <Files>, ou <VirtualHost>). La configuration se trouve généralement dans un fichier .conf (httpd.conf et apache.conf sont des noms couramment attribués à ces fichiers), ou dans un fichier .htaccess.

-
Header set Access-Control-Allow-Origin 'origin-list'
+
Header set Access-Control-Allow-Origin 'origin-list'

Pour Nginx, la commande pour mettre en place cet entête est :

-
add_header 'Access-Control-Allow-Origin' 'origin-list'
+
add_header 'Access-Control-Allow-Origin' 'origin-list'

Voir aussi

diff --git a/files/fr/web/http/cors/errors/corsdidnotsucceed/index.html b/files/fr/web/http/cors/errors/corsdidnotsucceed/index.html index 42b23087d6..1745ec854f 100644 --- a/files/fr/web/http/cors/errors/corsdidnotsucceed/index.html +++ b/files/fr/web/http/cors/errors/corsdidnotsucceed/index.html @@ -22,7 +22,7 @@ original_slug: Web/HTTP/CORS/Errors/CORSNAPasRéussi 
Raison: la requête CORS a échoué
-

Qu'est ce qui ne s'est pas bien passé ?

+

Qu'est ce qui ne s'est pas bien passé ?

La requête {{Glossary("HTTP")}} qui utilise le CORS a échoué à cause de la connection HTTP qui n'a pas aboutie soit au niveau du réseau, soit du protocole. L'erreur n'est pas directement lié au CORS, mais est une quelconque erreur réseau de base.

diff --git a/files/fr/web/http/cors/errors/corsmissingalloworigin/index.html b/files/fr/web/http/cors/errors/corsmissingalloworigin/index.html index 9eda6df7ea..e49b01ae2a 100644 --- a/files/fr/web/http/cors/errors/corsmissingalloworigin/index.html +++ b/files/fr/web/http/cors/errors/corsmissingalloworigin/index.html @@ -8,7 +8,7 @@ original_slug: Web/HTTP/CORS/Errors/CORSAllowOriginManquant

Symptomes

-
 Raison : l’en-tête CORS « Access-Control-Allow-Origin » est manquant.
+
 Raison : l’en-tête CORS « Access-Control-Allow-Origin » est manquant.

Quel est le problème ?

@@ -18,25 +18,25 @@ original_slug: Web/HTTP/CORS/Errors/CORSAllowOriginManquant

Par exemple, pour autoriser le site https://amazing.site à accéder aux resources avec CORS, le header doit être comme suit :

-
Access-Control-Allow-Origin: https://amazing.site
+
Access-Control-Allow-Origin: https://amazing.site

Vous pouvez aussi configurer le serveur pour autoriser tous les domaines à accéder aux ressources avec le caractère générique *. Ceci ne devrait être utilisé que pour des APIs publiques. Les APIs privées ne devraient jamais utiliser *, et devraient à la place utiliser un domaine ou un ensemble de domaines. De plus, l'astérisque ne fonctionne que pour les requêtes avec l'attribut {{htmlattrxref("crossorigin")}} ayant comme valeur anonymous.

-
Access-Control-Allow-Origin: *
+
Access-Control-Allow-Origin: *
-

Attention: Autoriser n'importe quel site à accéder à une API privée est une mauvaise idée.

+

Attention : Autoriser n'importe quel site à accéder à une API privée est une mauvaise idée.

Pour autoriser n'importe quel site à faire des requêtes CORS sans utiliser le caractère générique * (par exemple, pour fournir des authentifiants), votre serveur doit lire la valeur de l'entête Origin de la requête et l'utiliser dans Access-Control-Allow-Origin, tout en ajoutant une entête Vary: Origin pour indiquer que certaines entêtes sont définies dynamiquement selon leur origine.

L'instruction exacte pour définir les entêtes dépend de votre serveur Web. Par exemple, avec Apache, ajouter (dans la section <Directory>, <Location>, <Files>, ou <VirtualHost> appropriée) la ligne ci-dessous au fichier de configuration. Le fichier de configuration est en général un .conf (httpd.conf et apache.conf sont les noms les plus communs) ou un fichier nommé .htaccess.

-
Header set Access-Control-Allow-Origin 'origin-list'
+
Header set Access-Control-Allow-Origin 'origin-list'

Avec Nginx, la commande pour créer l'en-tête est :

-
add_header 'Access-Control-Allow-Origin' 'origin-list'
+
add_header 'Access-Control-Allow-Origin' 'origin-list'
diff --git a/files/fr/web/http/cors/errors/index.html b/files/fr/web/http/cors/errors/index.html index 30bb82d87f..17fa5f8e9b 100644 --- a/files/fr/web/http/cors/errors/index.html +++ b/files/fr/web/http/cors/errors/index.html @@ -16,7 +16,7 @@ translation_of: Web/HTTP/CORS/Errors ---
{{HTTPSidebar}}
-

Cross-Origin Resource Sharing ({{Glossary("CORS")}}) est une norme qui permet à un serveur d'assouplir la politique de même origine.

+

Cross-Origin Resource Sharing ({{Glossary("CORS")}}) est une norme qui permet à un serveur d'assouplir la politique de même origine.

Celle-ci est utilisée pour autoriser explicitement certaines requêtes provenant d'autres sources tout en en rejetant d'autres. Par exemple, si un site offre un service intégrable, il peut être nécessaire d'assouplir certaines restrictions. La configuration d'une telle configuration CORS n'est pas nécessairement facile et peut présenter certains défis. Dans ces pages, nous examinerons quelques messages d'erreur CORS courants et comment les résoudre.

@@ -33,16 +33,16 @@ translation_of: Web/HTTP/CORS/Errors
  • Essayez de reproduir la requête qui échoue et vérifiez la console pour trouver les messages de violation CORS, ce qui tournerait autours de:
    • -

    Firefox console showing CORS error

    +

    Firefox console showing CORS error

    Le text de l'erreur sera probablement similaire à:

    -
    Cross-Origin Request Blocked: The Same Origin Policy disallows
+
    Cross-Origin Request Blocked: The Same Origin Policy disallows
 reading the remote resource at https://some-url-here. (Reason:
-additional information here).
    
+additional information here).
    -

    Note: Pour des raisons de sécurité, il est impossible d'analyser les causes de l'erreur CORS via JavaScript. Seule une indication de l'échec de la requête sera fournie. Il faut donc absolument regarder manuellement les messages d'erreur de la console pour débugger.

    +

    Note : Pour des raisons de sécurité, il est impossible d'analyser les causes de l'erreur CORS via JavaScript. Seule une indication de l'échec de la requête sera fournie. Il faut donc absolument regarder manuellement les messages d'erreur de la console pour débugger.

    Messages d'erreur CORS

    diff --git a/files/fr/web/http/cors/index.html b/files/fr/web/http/cors/index.html index 6be35f1aaf..24d38600ac 100644 --- a/files/fr/web/http/cors/index.html +++ b/files/fr/web/http/cors/index.html @@ -18,7 +18,7 @@ translation_of: Web/HTTP/CORS

    Pour des raisons de sécurité, les requêtes HTTP multi-origine émises depuis les scripts sont restreintes. Ainsi, {{domxref("XMLHttpRequest")}} et l'API Fetch respectent la règle d'origine unique. Cela signifie qu'une application web qui utilise ces API peut uniquement émettre des requêtes vers la même origine que celle à partir de laquelle l'application a été chargée, sauf si des en-têtes CORS sont utilisés.

    -

    +

    Le CORS permet de prendre en charge des requêtes multi-origines sécurisées et des transferts de données entre des navigateurs et des serveurs web. Les navigateurs récents utilisent le CORS dans une API contenante comme {{domxref("XMLHttpRequest")}} ou Fetch pour aider à réduire les risques de requêtes HTTP multi-origines.

    @@ -55,9 +55,9 @@ translation_of: Web/HTTP/CORS

    Les fragments de code JavaScript (ainsi que les instances serveurs qui gèrent ces requêtes) se trouvent sur http://arunranga.com/examples/access-control/ et fonctionnent pour les navigateurs qui prennent en charge {{domxref("XMLHttpRequest")}} dans un contexte multi-site.

    -

    Un aperçu « côté serveur » des fonctionnalités CORS se trouve dans l'article Contrôle d'accès côté serveur.

    +

    Un aperçu « côté serveur » des fonctionnalités CORS se trouve dans l'article Contrôle d'accès côté serveur.

    -

    Requêtes simples

    +

    Requêtes simples

    Certaines requêtes ne nécessitent pas de requête CORS préliminaire. Dans le reste de cet article, ce sont ce que nous appellerons des requêtes « simples » (bien que la spécification {{SpecName('Fetch')}} (qui définit le CORS) n'utilise pas ce terme). Une requête simple est une requête qui respecte les conditions suivantes :

    @@ -88,13 +88,17 @@ translation_of: Web/HTTP/CORS
  • Aucun objet {{domxref("ReadableStream")}} n'est utilisé dans la requête.
    • -
    Note : Cela correspond aux classes de requêtes généralement produites par du contenu web. Aucune donnée de réponse n'est envoyée au client qui a lancé la requête sauf si le serveur envoie un en-tête approprié. Aussi, les sites qui empêchent les requêtes étrangères falsifiées ne craignent rien de nouveau.
    +
    +

    Note : Cela correspond aux classes de requêtes généralement produites par du contenu web. Aucune donnée de réponse n'est envoyée au client qui a lancé la requête sauf si le serveur envoie un en-tête approprié. Aussi, les sites qui empêchent les requêtes étrangères falsifiées ne craignent rien de nouveau.

    +
    -
    Note : WebKit Nightly et Safari Technology Preview ajoutent des restrictions supplémentaires pour les valeurs autorisées des en-têtes {{HTTPHeader("Accept")}}, {{HTTPHeader("Accept-Language")}} et {{HTTPHeader("Content-Language")}}. Si l'un de ces en-têtes a une valeur non-standard, WebKit/Safari considère que la requête ne correspond pas à une requête simple. Les valeurs considérées comme non-standard par WebKit/Safari ne sont pas documentées en dehors de ces bugs WebKit : Require preflight for non-standard CORS-safelisted request headers Accept, Accept-Language, and Content-Language, Allow commas in Accept, Accept-Language, and Content-Language request headers for simple CORS et Switch to a blacklist model for restricted Accept headers in simple CORS requests. Aucun autre navigateur n'implémente ces restrictions supplémentaires, car elles ne font pas partie de la spécification.
    +
    +

    Note : WebKit Nightly et Safari Technology Preview ajoutent des restrictions supplémentaires pour les valeurs autorisées des en-têtes {{HTTPHeader("Accept")}}, {{HTTPHeader("Accept-Language")}} et {{HTTPHeader("Content-Language")}}. Si l'un de ces en-têtes a une valeur non-standard, WebKit/Safari considère que la requête ne correspond pas à une requête simple. Les valeurs considérées comme non-standard par WebKit/Safari ne sont pas documentées en dehors de ces bugs WebKit : Require preflight for non-standard CORS-safelisted request headers Accept, Accept-Language, and Content-Language, Allow commas in Accept, Accept-Language, and Content-Language request headers for simple CORS et Switch to a blacklist model for restricted Accept headers in simple CORS requests. Aucun autre navigateur n'implémente ces restrictions supplémentaires, car elles ne font pas partie de la spécification.

    +
    -

    Si, par exemple, on a un contenu web situé sous le domaine http://toto.example qui souhaite invoquer du contenu situé sous le domaine http://truc.autre, on pourrait utiliser du code JavaScript semblable à ce qui suit sur toto.example :

    +

    Si, par exemple, on a un contenu web situé sous le domaine http://toto.example qui souhaite invoquer du contenu situé sous le domaine http://truc.autre, on pourrait utiliser du code JavaScript semblable à ce qui suit sur toto.example :

    -
    var invocation = new XMLHttpRequest();
+
    var invocation = new XMLHttpRequest();
 var url = 'http://truc.autre/resources/public-data/';
 
 function callOtherDomain() {
@@ -108,11 +112,11 @@ function callOtherDomain() {
 
 
    Cela entraînera un échange simple entre le client et le serveur laissant aux en-têtes CORS le soin de gérer les privilèges d'accès :
    
 
-
    
+
    
 
 
    Voyons dans le détail ce que le navigateur envoie au serveur et quelle sera sa réponse :
    
 
-
    GET /resources/public-data/ HTTP/1.1
+
    GET /resources/public-data/ HTTP/1.1
 Host: truc.autre
 User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
@@ -136,15 +140,15 @@ Content-Type: application/xml
 [XML Data]
 
    
 
-
    Les lignes 1 à 10 correspondent aux en-têtes envoyés. L'en-tête qui nous intéresse particulièrement ici est {{HTTPHeader("Origin")}}, situé à la ligne 10 : on y voit que l'invocation provient du domaine http://toto.example.
    
+
    Les lignes 1 à 10 correspondent aux en-têtes envoyés. L'en-tête qui nous intéresse particulièrement ici est {{HTTPHeader("Origin")}}, situé à la ligne 10 : on y voit que l'invocation provient du domaine http://toto.example.
    
 
-
    Les lignes 13 à 22 détaillent la réponse HTTP du serveur situé sous le domaine http://truc.autre. Dans la réponse, le serveur renvoie un en-tête {{HTTPHeader("Access-Control-Allow-Origin")}} (visible à la ligne 16). On voit ici les en-têtes {{HTTPHeader("Origin")}} et {{HTTPHeader("Access-Control-Allow-Origin")}} pour un contrôle d'accès dans sa forme la plus simple. Ici, le serveur répond avec Access-Control-Allow-Origin: * ce qui signifie que la ressource peut être demandée par n'importe quel domaine. Si les propriétés de la ressource située sous http://truc.autre souhaitaient restreindre l'accès à la ressource à l'origine http://toto.example, ils auraient renvoyé :
    
+
    Les lignes 13 à 22 détaillent la réponse HTTP du serveur situé sous le domaine http://truc.autre. Dans la réponse, le serveur renvoie un en-tête {{HTTPHeader("Access-Control-Allow-Origin")}} (visible à la ligne 16). On voit ici les en-têtes {{HTTPHeader("Origin")}} et {{HTTPHeader("Access-Control-Allow-Origin")}} pour un contrôle d'accès dans sa forme la plus simple. Ici, le serveur répond avec Access-Control-Allow-Origin: * ce qui signifie que la ressource peut être demandée par n'importe quel domaine. Si les propriétés de la ressource située sous http://truc.autre souhaitaient restreindre l'accès à la ressource à l'origine http://toto.example, ils auraient renvoyé :
    
 
-
    Access-Control-Allow-Origin: http://toto.example
    
+
    Access-Control-Allow-Origin: http://toto.example
    
 
-
    On notera que, dans ce cas, aucun autre domaine que http://toto.example (tel qu'identifié par l'en-tête Origin) ne pourra accéder à la ressource. L'en-tête Access-Control-Allow-Origin devrait contenir la valeur qui a été envoyée dans l'en-tête  Origin de la requête.
    
+
    On notera que, dans ce cas, aucun autre domaine que http://toto.example (tel qu'identifié par l'en-tête Origin) ne pourra accéder à la ressource. L'en-tête Access-Control-Allow-Origin devrait contenir la valeur qui a été envoyée dans l'en-tête  Origin de la requête.
    
 
-
    Requêtes nécessitant une requête préliminaire
    
+
    Requêtes nécessitant une requête préliminaire
    
 
 
    À la différence des requêtes simples, les requêtes préliminaires envoient d'abord une requête HTTP avec la méthode {{HTTPMethod("OPTIONS")}} vers la ressource de l'autre domaine afin de déterminer quelle requête peut être envoyée de façon sécurisée. Les requêtes entre différents sites peuvent notamment utiliser ce mécanisme de vérification préliminaire lorsque des données utilisateurs sont impliquées.
    
 
@@ -185,11 +189,13 @@ Content-Type: application/xml
  
  • Ou si un objet {{domxref("ReadableStream")}} est utilisé dans la requête.
    • 
 
 
-
    Note : WebKit Nightly et Safari Technology Preview ajoutent des restrictions supplémentaires pour les valeurs autorisées des en-têtes {{HTTPHeader("Accept")}}, {{HTTPHeader("Accept-Language")}} et {{HTTPHeader("Content-Language")}}. Si l'un de ces en-têtes a une valeur non-standard, WebKit/Safari considère que la requête ne correspond pas à une requête simple. Les valeurs considérées comme non-standard par WebKit/Safari ne sont pas documentées en dehors de ces bugs WebKit : Require preflight for non-standard CORS-safelisted request headers Accept, Accept-Language, and Content-Language, Allow commas in Accept, Accept-Language, and Content-Language request headers for simple CORS et Switch to a blacklist model for restricted Accept headers in simple CORS requests. Aucun autre navigateur n'implémente ces restrictions supplémentaires, car elles ne font pas partie de la spécification.
    
+
    
+  
    Note : WebKit Nightly et Safari Technology Preview ajoutent des restrictions supplémentaires pour les valeurs autorisées des en-têtes {{HTTPHeader("Accept")}}, {{HTTPHeader("Accept-Language")}} et {{HTTPHeader("Content-Language")}}. Si l'un de ces en-têtes a une valeur non-standard, WebKit/Safari considère que la requête ne correspond pas à une requête simple. Les valeurs considérées comme non-standard par WebKit/Safari ne sont pas documentées en dehors de ces bugs WebKit : Require preflight for non-standard CORS-safelisted request headers Accept, Accept-Language, and Content-Language, Allow commas in Accept, Accept-Language, and Content-Language request headers for simple CORS et Switch to a blacklist model for restricted Accept headers in simple CORS requests. Aucun autre navigateur n'implémente ces restrictions supplémentaires, car elles ne font pas partie de la spécification.
    
+
    
 
 
    Voici un exemple d'une requête qui devra être précédée d'une requête préliminaire :
    
 
-
    var invocation = new XMLHttpRequest();
+
    var invocation = new XMLHttpRequest();
 var url = 'http://truc.autre/resources/post-here/';
 var body = '<?xml version="1.0"?><personne><nom>Toto</nom></personne>';
 
@@ -209,7 +215,7 @@ function callOtherDomain(){
 
 
    Dans le fragment de code ci-avant, à la ligne 3, on crée un corps XML envoyé avec la requête POST ligne 8. Sur la ligne 9, on voit également un en-tête de requête HTTP non standard : X-PINGOTHER: pingpong. De tels en-têtes ne sont pas décrits par le protocole HTTP/1.1 mais peuvent être utilisés par les applications web. La requête utilisant un en-tête Content-Type qui vaut application/xml et un en-tête spécifique, il est nécessaire d'envoyer au préalable une requête préliminaire.
    
 
-
    pre-flight CORS french
    
+
    
 
 
    
 
    Note : Comme décrit après, la vraie requête POST n'inclut pas les en-têtes Access-Control-Request-* qui sont uniquement nécessaires pour la requête OPTIONS.
    
@@ -217,7 +223,7 @@ function callOtherDomain(){
 
 
    Voyons ce qui se passe entre le client et le serveur. Le premier échange est la requête/réponse préliminaire :
    
 
-
    OPTIONS /resources/post-here/ HTTP/1.1
+
    OPTIONS /resources/post-here/ HTTP/1.1
 Host: truc.autre
 User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
@@ -247,7 +253,7 @@ Content-Type: text/plain
 
 
    Une fois que la requête préliminaire est effectuée, la requête principale est envoyée :
    
 
-
    POST /resources/post-here/ HTTP/1.1
+
    POST /resources/post-here/ HTTP/1.1
 Host: truc.autre
 User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
@@ -282,7 +288,7 @@ Content-Type: text/plain
 
 
    Entre les lignes 1 à 12 qui précèdent, on voit la requête préliminaire avec la méthode {{HTTPMethod("OPTIONS")}}. Le navigateur détermine qu'il est nécessaire d'envoyer cela à cause des paramètres de la requête fournie par le code JavaScript. De cette façon le serveur peut répondre si la requête principale est acceptable et avec quels paramètres. OPTIONS est une méthode HTTP/1.1 qui est utilisée afin de déterminer de plus amples informations à propos du serveur. La méthode OPTIONS est une méthode « sûre » (safe) et ne change aucune ressource. On notera, qu'avec la requête OPTIONS, deux autres en-têtes sont envoyés (cf. lignes 10 et 11) :
    
 
-
    Access-Control-Request-Method: POST
+
    Access-Control-Request-Method: POST
 Access-Control-Request-Headers: X-PINGOTHER, Content-Type
 
    
 
@@ -290,7 +296,7 @@ Access-Control-Request-Headers: X-PINGOTHER, Content-Type
 
 
    Dans les lignes 14 à 26 qui suivent, on voit la réponse renvoyée par le serveur qui indique que la méthode de la requête (POST) ainsi que ses en-têtes (X-PINGOTHER) sont acceptables. Voici ce qu'on peut notamment lire entre les lignes 17 et 20 :
    
 
-
    Access-Control-Allow-Origin: http://toto.example
+
    Access-Control-Allow-Origin: http://toto.example
 Access-Control-Allow-Methods: POST, GET
 Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
 Access-Control-Max-Age: 86400
    
@@ -331,13 +337,13 @@ Access-Control-Max-Age: 86400
    
 
 
    Toutefois, si la requête déclenche une requête préliminaire suite à l'absence de l'en-tête {{HTTPHeader("Authorization")}}, on ne pourra pas utiliser cette méthode de contournement et il sera nécessaire d'avoir accès au serveur pour contourner le problème.
    
 
-
    Requêtes avec informations d'authentification
    
+
    Requêtes avec informations d'authentification
    
 
 
    Une des fonctionnalités intéressante mise en avant par le CORS (via {{domxref("XMLHttpRequest")}} ou Fetch) est la possibilité d'effectuer des requêtes authentifiées reconnaissant les cookies HTTP et les informations d'authentification HTTP. Par défaut, lorsqu'on réalise des appels {{domxref("XMLHttpRequest")}} ou Fetch entre différents sites, les navigateurs n'enverront pas les informations d'authentification. Pour cela, il est nécessaire d'utiliser une option spécifique avec le constructeur {{domxref("XMLHttpRequest")}} ou {{domxref("Request")}} lorsqu'on l'appelle.
    
 
-
    Dans cet exemple, le contenu chargé depuis http://toto.example effectue une requête GET simple vers une ressource située sous http://truc.autre qui définit des cookies. Voici un exemple de code JavaScript qui pourrait se trouver sur toto.example :
    
+
    Dans cet exemple, le contenu chargé depuis http://toto.example effectue une requête GET simple vers une ressource située sous http://truc.autre qui définit des cookies. Voici un exemple de code JavaScript qui pourrait se trouver sur toto.example :
    
 
-
    var invocation = new XMLHttpRequest();
+
    var invocation = new XMLHttpRequest();
 var url = 'http://truc.autre/resources/credentialed-content/';
 
 function callOtherDomain(){
@@ -351,11 +357,11 @@ function callOtherDomain(){
 
 
    À la ligne 7, on voit que l'option withCredentials, du constructeur {{domxref("XMLHttpRequest")}}, doit être activée pour que l'appel utilise les cookies. Par défaut, l'appel sera réalisé sans les cookies. Cette requête étant une simple requête GET, il n'est pas nécessaire d'avoir une requête préliminaire. Cependant, le navigateur rejettera tout réponse qui ne possède pas l'en-tête {{HTTPHeader("Access-Control-Allow-Credentials")}}: true et la réponse correspondante ne sera pas disponible pour le contenu web qui l'a demandée.
    
 
-
    
+
    
 
 
    Voici un exemple d'échange entre le client et le serveur :
    
 
-
    GET /resources/access-control-with-credentials/ HTTP/1.1
+
    GET /resources/access-control-with-credentials/ HTTP/1.1
 Host: truc.autre
 User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
@@ -388,13 +394,13 @@ Content-Type: text/plain
 [text/plain payload]
 
    
 
-
    Bien que la ligne 11 contienne le cookie pour le contenu sous http://truc.autre, si truc.autre n'avait pas répondu avec {{HTTPHeader("Access-Control-Allow-Credentials")}}: true (cf. ligne 19), la réponse aurait été ignorée et n'aurait pas pu être consommée par le contenu web.
    
+
    Bien que la ligne 11 contienne le cookie pour le contenu sous http://truc.autre, si truc.autre n'avait pas répondu avec {{HTTPHeader("Access-Control-Allow-Credentials")}}: true (cf. ligne 19), la réponse aurait été ignorée et n'aurait pas pu être consommée par le contenu web.
    
 
 
    Requêtes authentifiées et jokers (wildcards)
    
 
 
    Lorsqu'il répond à une requête authentifiée, le serveur doit indiquer une origine via la valeur de l'en-tête Access-Control-Allow-Origin, il ne doit pas utiliser le joker "*".
    
 
-
    Avec la requête précédente, on voit la présence d'un en-tête Cookie mais la requête échouerait si la valeur de l'en-tête de réponse Access-Control-Allow-Origin était "*". Ici, ce n'est pas le cas : Access-Control-Allow-Origin vaut "http://toto.example" et le contenu récupéré par la requête est alors envoyé au contenu web.
    
+
    Avec la requête précédente, on voit la présence d'un en-tête Cookie mais la requête échouerait si la valeur de l'en-tête de réponse Access-Control-Allow-Origin était "*". Ici, ce n'est pas le cas : Access-Control-Allow-Origin vaut "http://toto.example" et le contenu récupéré par la requête est alors envoyé au contenu web.
    
 
 
    Dans cet exemple, on notera également que l'en-tête de réponse Set-Cookie définit un autre cookie. En cas d'échec, une exception (dépendant de l'API utilisée) sera levée.
    
 
@@ -410,14 +416,14 @@ Content-Type: text/plain
 
 
    Une ressource de réponse peut avoir un en-tête {{HTTPHeader("Access-Control-Allow-Origin")}} avec la syntaxe suivante :
    
 
-
    Access-Control-Allow-Origin: <origin> | *
+
    Access-Control-Allow-Origin: <origin> | *
 
    
 
 
    Le paramètre origin définit un URI qui peut accéder à la ressource. Le navigateur doit respecter cette contrainte. Pour les requêtes qui n'impliquent pas d'informations d'authentification, le serveur pourra indiquer un joker ("*") qui permet à n'importe quelle origine d'accéder à la ressource.
    
 
 
    Si on souhaite, par exemple, autoriser http://mozilla.org à accéder à la ressource, on pourra répondre avec :
    
 
-
    Access-Control-Allow-Origin: http://mozilla.org
    
+
    Access-Control-Allow-Origin: http://mozilla.org
    
 
 
    Si le serveur indique une origine spécifique plutôt que "*", il pourra également inclure la valeur Origin dans l'en-tête de réponse {{HTTPHeader("Vary")}} pour indiquer au client que la réponse du serveur variera selon la valeur de l'en-tête de requête {{HTTPHeader("Origin")}}.
    
 
@@ -425,7 +431,7 @@ Content-Type: text/plain
 
 
    L'en-tête {{HTTPHeader("Access-Control-Expose-Headers")}} fournit une liste blanche des en-têtes auxquels les navigateurs peuvent accéder. Ainsi :
    
 
-
    Access-Control-Expose-Headers: X-Mon-En-tete-Specifique, X-Un-Autre-En-tete
+
    Access-Control-Expose-Headers: X-Mon-En-tete-Specifique, X-Un-Autre-En-tete
 
    
 
 
    Cela permettra que les en-têtes X-Mon-En-tete-Specifique et X-Un-Autre-En-tete soient utilisés par le navigateur.
    
@@ -434,7 +440,7 @@ Content-Type: text/plain
 
 
    L'en-tête {{HTTPHeader("Access-Control-Max-Age")}} indique la durée pendant laquelle le résultat de la requête préliminaire peut être mis en cache (voir les exemples ci-avant pour des requêtes impliquant des requêtes préliminaires).
    
 
-
    Access-Control-Max-Age: <delta-en-secondes>
+
    Access-Control-Max-Age: <delta-en-secondes>
 
    
 
 
    Le paramètre delta-en-seconds indique le nombre de secondes pendant lesquelles les résultats peuvent être mis en cache.
    
@@ -443,16 +449,16 @@ Content-Type: text/plain
 
 
    L'en-tête {{HTTPHeader("Access-Control-Allow-Credentials")}} indique si la réponse à la requête doit être exposée lorsque l'option credentials vaut true. Lorsque cet en-tête est utilisé dans une réponse préliminaire, cela indique si la requête principale peut ou non être effectuée avec des informations d'authentification. On notera que les requêtes GET sont des requêtes simples et si une requête est effectuée, avec des informations d'authentification pour une ressource, et que cet en-tête n'est pas renvoyé, la réponse sera ignorée par le navigateur et sa charge ne pourra pas être consommée par le contenu web.
    
 
-
    Access-Control-Allow-Credentials: true
+
    Access-Control-Allow-Credentials: true
 
    
 
-
    Voir les scénarios ci-avant pour des exemples.
    
+
    Voir les scénarios ci-avant pour des exemples.
    
 
 
    Access-Control-Allow-Methods
    
 
 
    L'en-tête {{HTTPHeader("Access-Control-Allow-Methods")}} indique la ou les méthodes qui sont autorisées pour accéder à la ressoure. Cet en-tête est utilisé dans la réponse à la requête préliminaire (voir ci-avant les conditions dans lesquelles une requête préliminaire est nécessaire).
    
 
-
    Access-Control-Allow-Methods: <methode>[, <methode>]*
+
    Access-Control-Allow-Methods: <methode>[, <methode>]*
 
    
 
 
    Voir un exemple ci-avant pour l'utilisation de cet en-tête.
    
@@ -461,7 +467,7 @@ Content-Type: text/plain
 
 
    L'en-tête {{HTTPHeader("Access-Control-Allow-Headers")}} est utilisé dans une réponse à une requête préliminaire afin d'indiquer les en-têtes HTTP qui peuvent être utilisés lorsque la requête principale est envoyée.
    
 
-
    Access-Control-Allow-Headers: <nom-champ>[, <nom-champ>]*
+
    Access-Control-Allow-Headers: <nom-champ>[, <nom-champ>]*
 
    
 
 
    En-têtes de requête HTTP
    
@@ -472,12 +478,14 @@ Content-Type: text/plain
 
 
    L'en-tête {{HTTPHeader("Origin")}} indique l'origine de la requête (principale ou préliminaire) pour l'accès multi-origine.
    
 
-
    Origin: <origine>
+
    Origin: <origine>
 
    
 
 
    L'origine est un URI qui indique le serveur à partir duquel la requête a été initiée. Elle n'inclut aucune information relative au chemin mais contient uniquement le nom du serveur.
    
 
-
    Note : origine peut être une chaîne vide (ce qui s'avère notamment utile lorsque la source est une URL de donnée).
    
+
    
+  
    Note : origine peut être une chaîne vide (ce qui s'avère notamment utile lorsque la source est une URL de donnée).
    
+
    
 
 
    Pour chaque requête avec contrôle d'accès, l'en-tête {{HTTPHeader("Origin")}} sera toujours envoyé.
    
 
@@ -485,7 +493,7 @@ Content-Type: text/plain
 
 
    L'en-tête {{HTTPHeader("Access-Control-Request-Method")}} est utilisé lorsqu'on émet une requête préliminaire afin de savoir quelle méthode HTTP pourra être utilisée avec la requête principale.
    
 
-
    Access-Control-Request-Method: <methode>
+
    Access-Control-Request-Method: <methode>
 
    
 
 
    Voir ci-avant pour des exemples d'utilisation de cet en-tête.
    
@@ -494,7 +502,7 @@ Content-Type: text/plain
 
 
    L'en-tête {{HTTPHeader("Access-Control-Request-Headers")}} est utilisé lorsqu'on émet une requête préliminaire afin de communiquer au serveur les en-têtes HTTP qui seront utilisés avec la requête principale.
    
 
-
    Access-Control-Request-Headers: <nom-champ>[, <nom-champ>]*
+
    Access-Control-Request-Headers: <nom-champ>[, <nom-champ>]*
 
    
 
 
    Voir ci-avant pour des exemples d'utilisation de cet en-tête.
    
@@ -532,7 +540,7 @@ Content-Type: text/plain
 
  
-
-
-
    
-
-
-
-
    
+
\ No newline at end of file
-- 
cgit v1.2.3-54-g00ecf