web-dev-qa-db-fra.com

WebSocket sur IE10 avec une SecurityError

Je développe actuellement un site Web sous IE10 (sous Windows 8), en utilisant WebSockets en JavaScript. Il fonctionne bien sous Firefox 18 et Chrome 25, mais sur IE10, je reçois une erreur SecurityError lorsque j'établis la connexion.

Ce que je fais semble assez poussé vers l'avant:

websocket = new WebSocket('wss://hello.dev.mydomain.net');

Mais IE n'aime pas ça:

SCRIPT5022: SecurityError 

Le script est sur " https://test.dev.mydomain.net " (pas l'adresse réelle évidemment).

Ce qui me dérange, c’est que si je double-clique simplement sur le fichier sur mon ordinateur local (par exemple, fichier: // ...), cela fonctionne. Pire encore: si j’utilise fiddler pour surveiller le trafic HTTP ... cela se passe {fonctionne également} _. Considérant qu'il semble n'y avoir aucune connexion du tout sans fiddler, comme détaillé dans les spécifications de l'API. (Voir ci-dessous.)

À en juger par websocket spec , l'exception devrait également apparaître sur Chrome/Firefox ... mais ce n'est pas le cas. Donc, je doute que cela ait quelque chose à voir avec HTTP/HTTPS. En tout cas, j'utilise un socket wsS sur une page httpS ... De plus: quand je remplace l'adresse wss par un autre serveur valide trouvé sur un exemple en ligne, cela fonctionne.

Je ne sais pas si cela est pertinent, mais l'adresse IP de test.dev.mydomain.net est 10.14.x.x, où hello.dev.mydomain.net est 194.247.x.x. Je ne sais pas si cela pourrait déclencher une sorte de sécurité sur IE uniquement ...

Une dernière chose: j'ai un certificat pour * .dev.mydomain.net, IE ne semble pas avoir de problèmes avec cela. Le script réside à l'origine sur un serveur appelé mon.nom.dev.mydomain.net, mais comme j'y accède depuis une autre URL (j'ai reçu une redirection depuis que nous pensions que cela aurait pu être une sorte de problème de politique de même origine). Je ne vois pas en quoi cela pourrait avoir de l'importance. Au moins j'espère que ça ne va pas ...

Toute idée est la bienvenue.

EDIT: l'ajout des sites à la zone de confiance ne fonctionne pas non plus.

38
EldredB

Eh bien, ma question n’a pas eu autant de succès, alors je vais poster la "solution de contournement" que j’ai trouvée.

J'ai eu une autre adresse pour le site web, en 194.247.. aussi. Ceci, comme par magie, l'a résolu. Je suppose que IE n'aime pas mélanger des éléments locaux et externes et surveille l'adresse IP.

Quoi qu'il en soit, j'espère que cela pourra être utile à quiconque a le même problème.

Si vous avez une solution pour résoudre le "vrai" problème en configurant IE, faites-le moi savoir :)

À votre santé,

6
EldredB

Il semble que IE lève une erreur SecurityError si vous essayez d'ouvrir une prise Web sur un domaine local (intranet). Pour résoudre ce problème, vous pouvez désactiver l'algorithme automatique d'IE pour la reconnaissance des sites locaux. Cela peut être fait dans Tools > Internet Options > Security > Local Intranet > Sites.

intranet detection settings

Décochez toutes les cases (ou une seule, si vous savez exactement comment votre domaine s'est retrouvé dans l'intranet). 

Notez que IE utilise (entre autres choses) ses paramètres de proxy pour déterminer les sites locaux: si votre domaine est répertorié comme exclu du proxy dans les paramètres de proxy, il sera probablement traité comme un intranet. C’est pourquoi WebSockets fonctionne si vous activez Fiddler: il modifie les paramètres du proxy IE et la liste des sites intranet est donc modifiée.

47
Georgii Ivankin

J'ai eu ce problème dans Windows7/IE11 after en appliquant un correctif de sécurité. Pour Windows10/Edge, c'est la même histoire. 

Comme il s'agit d'un socket Web local (ws: // localhost), vous devez ajouter ws:\\localhost\ aux configurations Internet Explorer (Outils> Options Internet> Sécurité> Intranet local> Sites> Avancés). 

 IE11 local intranet sites configuration

Dans Windows 10/Microsoft Edge, vous trouverez cette configuration dans Panneau de configuration> Options Internet.

METTRE À JOUR

L'adresse de votre application Web ( https://test.dev.mydomain.net ) doit également être ajoutée à la zone intranet locale. Note que dans l'image, l'adresse Webapp doit être ajoutée.

5
lmiguelmh

Le nom d’hôte/adresse IP du client doit être identique à celui du serveur IP/nom d’hôte, sinon vous obtiendrez l’erreur susmentionnée.

1) Assurez-vous que le nom d’hôte du serveur est configuré pour écouter sur IP/localhost etc.

2) utilisez le même nom d’hôte dans le client. Cela résoudra le problème. Cela a fonctionné pour moi ...

1
Lokesh

Les navigateurs ont une limitation websocket. Par exemple, Internet Explorer a une limite par défaut de connexions websocket définie sur 6 par nom d'en-tête d'hôte. la même limitation est définie pour le composant WinForms WebBrowser.

La solution consiste à ajouter des valeurs sous la clé Ordinateur \HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_WEBSOCKET_MAXCONNECTIONSPERSERVER in. Ajoutez simplement une valeur DWORD avec un nom d’exécutable, par exemple iexplore.exe (ou le nom d’exécutable de votre application si vous utilisez un composant de navigateur Web) et définissez une valeur comprise dans la plage 2..128.

La deuxième option pour résoudre SecurityException consiste à créer plusieurs sous-domaines.

1
Rudolf Dvoracek

J'ai rencontré l'erreur (bien qu'il ne soit pas indiqué dans la partie SCRIPT5022, il indique simplement "ScriptError"). J'ai contourné le problème en cliquant sur "Sites de confiance" puis en ajoutant la machine hébergeant le Websocket distant. Remarque, pour ajouter aux sites de confiance,

  • Je devais fournir l'adresse sans la partie "ws: //" (juste comme mymahcine.mydomain.com)

  • Je devais décocher la case "Exiger la vérification du serveur https: //".

  • Après avoir ajouté le domaine, j'ai co-coché la case "Exiger une vérification du serveur (https: //). Je recommanderais à tout le monde de faire de même. Décocher la case n'est qu'une solution pour ajouter des sites qui ne commencent pas par https (plutôt ws: // dans mon cas)
0
NurAlDin

Le même problème se posait dans l'un des environnements de mes clients… .. Il s'est avéré qu'ils avaient une configuration de proxy qui ne permettait pas la connexion directe au point de terminaison WebSocket et ne supportait pas le protocole WebSocket désactiver en utilisant le proxy et tout a commencé à fonctionner. La solution à long terme consiste à modifier la configuration du proxy (fichier .pac) pour exclure l'adresse du noeud final WebSocket.

Pour désactiver le proxy, accédez à: Options Internet Explorer> onglet Connexions> bouton Paramètres réseau> décocher Détecter automatiquement les paramètres.

J'espère que ça aide quelqu'un.

0
DoronG