Pourquoi les demandes CORS échouent-elles dans Microsoft Edge mais fonctionnent-elles dans d'autres navigateurs?
J'utilise jQuery pour envoyer des demandes ajax croisées d'origine et elles fonctionnent correctement dans IE11, Chrome et Firefox, mais elles échouent dans Edge avec l'erreur suivante:
SCRIPT7002: XMLHttpRequest: Erreur réseau 0x80070005, l'accès est refusé.
Ce qui est intéressant, c'est que j'ai utilisé Fiddler pour essayer de comprendre ce qui se passait et quand Fiddler est en cours d'exécution et de capture des demandes, tout fonctionne bien. Dès que je ferme Fiddler ou suspend la capture, il échoue à nouveau.
Le site s'exécute sur ma machine locale (webpack-dev-server), effectuant des requêtes sur le réseau local vers un service WebAPI.
Mon fichier d'hôtes est configuré comme ceci:
127.0.0.1 local.myapp.test
192.168.0.111 api.myapp.test
Cela ne devrait pas être un problème en production car le site et l'API seront hébergés au même endroit mais c'est inestimable pour le développement et les tests.
Mise à jour:
Grâce à Eric Law, je sais maintenant pourquoi il se comportait différemment avec Fiddler activé - Edge passait à la zone Intranet local en raison des changements de paramètres de proxy effectués par Fiddler et la zone intranet a un niveau de sécurité inférieur.
Je vais faire passer le niveau de sécurité de la zone intranet locale à moyen-élevé pour correspondre à la zone Internet, puis utiliser Fiddler pour essayer de comprendre pourquoi Edge est contrarié par la demande CORS.
J'inclus ci-dessous, textuellement, les réponses qu'Eric Lawrence (créateur de Fiddler) a aimablement fournies sur le forum Fiddler:
Une possibilité est que votre ordinateur soit configuré avec une zone Intranet et que la zone Intranet dépende d'un script de configuration de proxy: http://blogs.msdn.com/b/ieinternals/archive/2012/06/05/ the-local-intranet-security-zone.aspx . Lorsque Fiddler est en cours d'exécution, les paramètres de proxy pointent sur Fiddler lui-même.
... il y a un autre facteur à l'œuvre ici si vous utilisez un site Intranet comme cible d'un XHR à partir d'un site dans la zone Internet.
Edge s'exécute en mode protégé amélioré (AppContainer). Cela a une fonctionnalité qui bloque l'accès aux ressources du réseau privé à partir des processus de la zone Internet. Voir la section "Ressources du réseau privé" de http://blogs.msdn.com/b/ieinternals/archive/2012/03/23/understanding-ie10-enhanced-protected-mode-network-security-addons -cookies-metro-desktop.aspx pour plus de détails.
J'ai ajouté local.myapp.test (l'URL à partir de laquelle j'exécute mon SPA) à la zone Intranet local dans Options Internet et maintenant Edge est satisfait sans avoir besoin de Fiddler.
Je suis tombé sur cette question et après avoir essayé plusieurs options, ce qui a fonctionné pour moi a été de supprimer le domaine sur lequel je travaille de toutes les entrées du site Zone. En utilisant local.myapp.test comme exemple, j'ai vérifié les entrées "anysubdomain" .myapp.test et les ai supprimées de toutes les zones, y compris tous les sous-domaines ou entrées génériques.
Dans Options Internet (IE 11), sélectionnez sécurité onglet, et dans "Intranet local" cliquez sur "sites" puis "Avancé "et supprimé les références de domaine pertinentes.
Dans "Sites de confiance" cliquez sur "sites" et supprimez les entrées pertinentes de la liste
Dans environ: les indicateurs à l'intérieur d'Edge s'assurent que "Autoriser le bouclage localhost (cela pourrait mettre votre appareil en danger)" est coché.