Est-il possible de piéger les erreurs CORS?
Cette question est liée au partage de ressources d'origine croisée (CORS, http://www.w3.org/TR/cors/ ).
S'il y a une erreur lors d'une demande CORS, Chrome (et AFAIK d'autres navigateurs également) enregistre une erreur dans la console d'erreur. Un exemple de message peut ressembler à ceci:
XMLHttpRequest ne peut pas charger
http://domain2.example. L'originehttp://domain1.exampleN'est pas autorisée par Access-Control-Allow-Origin.
Je me demande s'il existe un moyen d'obtenir par programme ce message d'erreur? J'ai essayé d'encapsuler mon appel xhr.send() dans try/catch, j'ai également essayé d'ajouter un gestionnaire d'événement onerror(). Aucun d'eux ne reçoit le message d'erreur.
Voir:
... ainsi que des notes dans XHR Level 2 sur CORS:
Les informations sont intentionnellement filtrées.
Modifier plusieurs mois plus tard: Un commentaire de suivi ici a demandé "pourquoi"; il manquait quelques caractères à l'ancre du premier lien, ce qui rendait difficile de voir à quelle partie du document je faisais référence.
C'est une question de sécurité - une tentative pour éviter d'exposer des informations dans les en-têtes HTTP qui pourraient être sensibles. Le lien du W3C sur CORS dit:
Les agents utilisateurs doivent filtrer tous les en-têtes de réponse autres que ceux qui sont un simple en-tête de réponse ou dont le nom de champ est une correspondance ASCII insensible à la casse pour l'une des valeurs de Access-Control- En-têtes Expose-Headers (le cas échéant), avant d'exposer les en-têtes de réponse aux API définies dans les spécifications de l'API CORS.
Ce passage comprend des liens pour "en-tête de réponse simple", qui répertorie Cache-Control, Content-Language, Content-Type, Expires, Last-Modified et Pragma. Donc, ceux-ci sont passés. La partie "En-têtes Access-Control-Expose-Headers" permet également au serveur distant d'exposer d'autres en-têtes en les listant dedans. Consultez la documentation du W3C pour plus d'informations.
N'oubliez pas que vous avez une origine - disons que c'est la page Web que vous avez chargée dans votre navigateur, exécutant un peu de JavaScript - et que le script fait une demande à une autre origine, ce qui n'est généralement pas autorisé car les logiciels malveillants peuvent faire des choses désagréables qui façon. Ainsi, le navigateur, exécutant le script et exécutant les requêtes HTTP en son nom, agit comme contrôleur d'accès.
Le navigateur examine la réponse de cet "autre serveur d'origine" et, s'il ne semble pas "participer" à CORS - les en-têtes requis sont manquants ou mal formés - alors nous sommes dans une position de défiance. Nous ne pouvons pas être sûrs que le script exécuté localement agit de bonne foi, car il semble essayer de contacter des serveurs qui ne s'attendent pas à être contactés de cette manière. Le navigateur ne devrait certainement pas "divulguer" des informations sensibles de ce serveur distant en passant simplement toute sa réponse au script sans filtrage - ce serait essentiellement permettant une demande d'origine croisée, en quelque sorte. Une vulnérabilité de divulgation d'informations se présenterait.
Cela peut rendre le débogage difficile, mais c'est un compromis sécurité/convivialité où, "l'utilisateur" étant un développeur dans ce contexte, la sécurité se voit accorder une priorité importante.