My web app is failing when I test it in BrowserStack, it breaks in the detectizr.js file, where navigator.plugins is being accessed. When I look at the navigator object via dev tools, I can see that for plugins there is a message saying permission denied and want to confirm if this is why my web app breaks in IE Edge and no other web browser. Has anyone encountered this issue? I am wondering if perhaps it's only an IE14 Edge setting that needs to be changed.
I've seen this same issue in IE Edge on BrowserStack when accessing navigator.plugins. I am using socket.io-client.js which uses this check to see if Flash is enabled. I don't see this issue on my actual Windows computers, so I believe you are on the right track that it is something specific to BrowserStack.
sorry - i wanted to comment not answer, but i don't have a good enough reputation to comment yet. guess i'm not allowed to be helpful yet :(
This line:
var socket = new WebSocket(this.getUrl());
Causes error:
WebSocket connection to 'ws://127.0.0.1:6437/v6.json' failed: Error during WebSocket handshake: Unexpected response code: 400
I'm guessing I could get around it by using SSL but as I’m just playing around locally with MAMP it would be nice not to have to set this up. I get the same from Chrome, Firefox and Safari. The context is that I’m playing with a Leap Motion controller and everything works fine as long as it’s running remotely with SSL.
Do I really need SSL for all local development using web sockets or am I missing something?
You don't need SSL/TLS to use WebSockets unless you are connecting from a page that is also using SSL/TLS -- I'm looking t such a page right now and it works fine. Do the sample apps (Sample.html and JSONViewer.html) in the Leap Motion SDK work for you?
I'm trying to use websockets in a web page with javascript, ('ws://localhost:9090') but get the following error from firefox:
"Caught exception while dispatching event:
The operation is insecure."
If I change the url of the websocket to 'wss://localhost:9090' I get another error:
Firefox can't establish a connection to the server at wss://localhost:9090/.
The javascript I'm working on is meant to communicate with the ros operating system on a robot that has it installed. How can I enable websockets in this special situation? I was using google chrome because of the limitations on firefox, but after a recent update of chrome, it seems impossible there too. On chrome I get another error.
I am currently developing a website under IE10 (on Windows 8), using WebSockets in JavaScript. It runs fine under Firefox 18 and Chrome 25, but on IE10 I get a SecurityError when I establish the connection.
What I am doing seems pretty straghtforward :
websocket = new WebSocket('wss://hello.dev.mydomain.net');
But IE doesn't like it :
SCRIPT5022: SecurityError
The script is on "https://test.dev.mydomain.net" (not the real address obviously).
What bothers me is that if I just double-click the file on my local computer (e.g. file://...) it just works. Even worse: if I use fiddler to monitor HTTP traffic... it also works. Whereas there seems to be no connection at all without fiddler, as detailed in the API's specs. (See below.)
Judging by websocket spec, the exception should also appear on Chrome/Firefox... but it does not. So I doubt it has anything related to HTTP/HTTPS. In any case, I am using a wsS socket on a httpS page... Moreover: when I replace the wss address by another valid server found on an online example, it works.
I don't know if this is relevant, but the IP from test.dev.mydomain.net is 10.14.x.x where hello.dev.mydomain.net is 194.247.x.x. I don't know if it could trigger some kind of security on IE only...
One more thing: I have a certificate for *.dev.mydomain.net, IE does not seems to have problems with it. The script originally resides on a server called my.name.dev.mydomain.net, but since I am accessing it from another URL (I got a redirect since we first thought it could have been some kind of Same Origin Policy issue), I don't see how it could matter. At least I hope it does not...
Any idea is welcomed.
EDIT: adding the sites to the trusted zone does not work either.
It looks like IE throws a SecurityError if you're trying to open a websocket on a local (intranet) domain. To overcome this, you may disable IE's automatic algorithm for recognizing local sites. This can be done in Tools > Internet Options > Security > Local Intranet > Sites.
Uncheck all checkboxes (or only a particular one, if you know how exactly your domain did end up in intranet ones).
Note that IE uses (among other things) its proxy settings to determine local sites: if your domain is listed as excluded from proxying in proxy settings, then it will probably be treated as intranet one. This is why WebSockets work if you enable Fiddler: it modifies IE proxy settings and thus the list of intranet sites changes.
I had this problem in Windows7/IE11 after applying a security patch. For Windows10/Edge is the same story.
As this is a local websocket (ws://localhost) you have to add ws:\\localhost\ to Internet Explorer configurations (Tools > Internet Options > Security > Local Intranet > Sites > Advanced).
In Windows 10/Microsoft Edge you will find this configuration in Control Panel > Internet Options.
UPDATE
The address of your webapp (https://test.dev.mydomain.net) must be added to the local intranet zone too. Note that in the image the webapp address should be added.
Well, my question wasn't that successful, so I'll post the "workaround" I found.
I got another address for the website, in 194.247.. too. This, magically, solved it. Guess IE doesn't like mixing local and external stuff and watches the IP.
Anyways, I hope this may come in handy to anyone who's got the same issue.
If you have a solution to solve the "real" issue by configuring IE, let me know :)
Cheers,
Browsers has a websocket limitation. For example Internet Explorer has default limit of websocket connections set to 6 per host header name. the same limitation is set for WinForms WebBrowser component.
The solution is to add values under key Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_WEBSOCKET_MAXCONNECTIONSPERSERVER in registry. Just add DWORD value with executable name , for example iexplore.exe (or your application executable name if you use Web browser component) and set value from range 2..128
Second option how to solve SecurityException is to create multiple subdomains.
The client hostname/IP Address should be same as server IP/Hostname thats listening to otherwise you would get the above error.
1) Make sure whether server hostname configured to listen at IP/localhost etc andif not explicitly specify the hostname ast server
2) use the same hostname in the client. THis will solve the issue. It worked for me...
I encountered the error (although it did not say the SCRIPT5022 part, rather it just reports "ScriptError"). I got around the issue by clicking on "Trusted Sites" and then adding the machine hosting the remote websocket. Note, to add to trusted sites,
I had to supply the address without the "ws://" part (like just mymahcine.mydomain.com)
I had to uncheck the box that says "Require server verification https:// " option.
After I was done adding the domain, I re-checked the box "Require server verification (https://). I would recommend everyone to do the same. Unchecking the box is only a workaround to add sites that don't begin with https (rather ws:// in my case)
I had the same issue at one of my customer's environment.
It turned out that they had a proxy configuration that did not allow the connection to the WebSocket endpoint directly and did not support the WebSocket protocol.
The temporary solution was to disable using the proxy and everything started working. The long term solution is to edit the proxy's configuration (.pac file) to exclude the address of the WebSocket endpoint.
To disable the proxy, go to: Internet Explorer Options > Connections tab > LAN settings button > un-check Automatically detect settings.
Hope this helps someone.
In addition to making sure that the internet zone is not localhost (as in above answers), ensure that if https is used, then wss should be used.
This is not an issue in other browsers, but IE is abit more finicky.
I develop a Chrome plugin that uses XMLHttpRequest to send a GET HTTP request with an username/password to a basic-auth-protected URL, so that it can then "auto-login" to it afterwards (since Chrome caches credentials for HTTP basic-auth).
Here's the code I use:
var xml = new XMLHttpRequest();
xml.open('GET',<url>,false,<username>,<password>)
xml.send('');
It used to work fine for quite a while, but started failing some time ago. The plugin code hasn't changed, so I thought it could have to do with Chrome itself. I downloaded a previous version for OSX (17) and BAM, it worked again.
After some additional research, I found out that it might have to do with Chrome 19 not supporting the username:pwd#url syntax for authenticating to basic-auth protected URLs, because when I send the XMLHttpRequest, I see this in Google Chrome's js console:
GET http://user:pass#domain.com 401 (Unauthorized)
Does anyone know whether it's a bug or if Chrome stopped supporting this feature?
Thanks,
Marcelo.
You are not the only person having this issue. It's ruffled several other people's feathers.
However, given the comments from the Chromium Developers:
The support for embedded auth in URLs was intentionally deprecated.
It looks like it was removed intentionally.