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.
Related
I'm writing an application that first tries to open a WebSocket connection (to make sure no others are open; address collision checking) before firing off a custom protocol that will launch a one-time WebSocket server with the address that the browser tells it. All communication is done over localhost and some arbitrary port number, say 3000. I'm not doing anything special, just attempting to open a WebSocket:
var socket = new WebSocket("ws://localhost:3000/MyApp/");
socket.onclose = function(e) { console.error(e); }
When testing in Chrome, the WebSocket will actually stay in the CONNECTING state for a little bit, which is ideal, since it gives us some time to actually launch the app through the custom protocol. But in Firefox, the WebSocket immediately closes with code 1006 and I can't figure out why.
I've tried changing the about:config network.websocket.timeout.open setting to be 1000 (from 20), but that doesn't help. I've also found this related post: Websockets - chrome and firefox differences?. That hasn't lead me to finding an answer, either.
What am I missing?
Update 11/16/21
I'm using the Dev Tools in Chrome and FF to check out the requests. The weird thing is that Chrome is actually sending a request header as you'd expect, but in FF, the request is completely empty (0 Bytes). Maybe this is a problem with FF not supporting debugging native WebSockets (no wrapper libraries in use)? Is there some FF setting that nixes the request? But even more confusing is that the browser would hit the close event without ever hitting the open event.
Update 11/17/21
I realize that maybe this has something to do with launching a Custom Protocol Handler? I noticed that it will wait a second to try and connect to a web server if no CPH is launched, but then when I do launch a CPH, that is when it immediately closes the WebSocket. The CPH is launched via a link targeting "_parent".
It looks like the custom protocol is causing FF to stop trying to connect early. I created an anchor element, <a>, in the JS code and called "click()" on it after constructing it. No matter what target I gave it (e.g. _self), it would cause the connection attempt to stop.
So long story short, initiating a link, whether it be a a.click, window.open, or location.replace, will cause Firefox to nix any currently polling WebSockets!
The workaround is to just use an iframe to launch the custom protocol.
I want to add VPN client support to an existing chrome extension. I noticed that chrome has an API named 'networkingPrivate' for many network configurations. I kick started with a java script that calls some of the methods provided by networkingPrivate API. But, I'm facing chrome.networkingPrivate 'undefined' error. Any reference on how to use the API in a chrome extension would be of great help!
Chrome OS only, kiosk apps only (not extensions), dev channel only, and it is being renamed.
https://developer.chrome.com/apps/networking_onc
You probably want chrome.vpnProvider instead anyway, but that's still Chrome OS only.
I'm getting following error while connecting to websocket's in safari, In remaining browsers it is working fine
Error:
WebSocket network error: OSStatus Error -9807: Invalid certificate chain
Code:
var websocket = new WebSocket("wss://localhost:44300/websocketHome", "Room_123")
The workaround is to enable NSURLSession Websocket in Settings > Safari > Advanced > Experimental Features > NSURLSession Websocket. Should work on iOS 13.4.1+.
Note this may not be suitable for production environments.
So I'm going to start this answer with a caveat: I'm not an expert in WebSockets, Browsers, Safari, or URLs. The reason I mention this is that I don't know why this solution works and I don't know why Safari behaves in the way that it does.
I spent a good couple of hours figuring out why my site wasn't working in Safari, but was working in every other browser. And it pisses me off, because I don't have time for this rubbish.
Essentially what you need to do is replace this:
var websocket = new WebSocket("wss://localhost:44300/websocketHome", "Room_123")
with this:
var websocket = new WebSocket("ws://localhost:44300/websocketHome", "Room_123")
But don't kick yourself yet, because you weren't imagining it when it worked in Chrome and Firefox. Safari seems to be the only browser enforcing the protocol part of the URL, i.e. "ws" instead of "wss" for localhost connections.
Basically I don't have time to research if Safari is following the standard properly or not, but it doesn't matter, because I'm going to chalk this up as yet another example of Safari(the Internet Explorer of 2017) unnecessarily breaking from the herd to make life difficult for web developers.
If Apple want to enforce standards that the other browsers don't, they're welcome to do that, but they at least need to print useful errors, WebSocket network error: OSStatus Error -9807: Invalid certificate chain isn't good enough.
Edit
This will be obvious to most people, but for those who aren't professional developers, make sure you don't deploy this change to production. You want to be using the wss protocol for production, and that should work fine on Safari if you've got your certificates set up properly.
We ran into this error, secure WebSockets weren't working in newer versions of OSX under Safari and Chrome, with a LetsEncrypt certificate. The fix for us was to replace references to "cert.pem" with "fullchain.pem", as described in this link
https://community.letsencrypt.org/t/issues-on-mac-with-wss-osstatus-error-9807-invalid-certificate-chain/160930
I was hoping google chrome socket connections from a chrome extension would go through the proxy settings of the browser but it does not seem to be the case.
Any idea of how could I automagically connect to a server and let chrome bothering with the proxy ?
Currently you can't, but we expect that this will be possible using a network proxy API when the bug http://crbug.com/172285 gets implemented.
If you want, star the issue to follow the development.
I did the mistake of creating my entire web application and not testing it on IE along the way. I only tested it on Firefox and Safari. The web app runs fine on both Safari and Firefox but it gives a Permission Denied error on IE.
I am using Google AuthSub authentication and so for authenticating using Google Account, it first redirects to allow the app access to Google Account. After authentication, IE changes 'http' to 'https'. This does not happen with either Firefox or Safari. They remain with the 'http' protocol.
IE then gives a Permission Denied error. Is the JavaScript conflicting with 'https' in any way?
The app is here -> http://ankitahuja.com/apps/proxycal
and the error-causing page is -> http://ankitahuja.com/apps/proxycal/proxycal.php
When I open up the proxycal.php page in both IE and FF, an error is raised on this line in the Javascript (in function _run):
calendarService = new google.gdata.calendar.CalendarService('proxycal');
Here, calendar is not a member of google.gdata.
I suggest you debug through the call stack to find out what is not being initialized.
I've run into that error before in IE. Most often, it was because I was fetching data from another domain using XmlHttpRequest. Check the "allow data from other domains" setting in IE's Internet Options, make sure it's allowed and then see if you get the same error.
In IE you can use XDomainRequest, but not for https from http, which is blocked and This is an expected by-design behavior (though not expected in FF/Chrome)