Support configuration for WebSockets SSL

[tylerduni]

var connection = new WebSocket('ws://' + host + ':' + port);

Need to to be able to configure use of SSL, like this:

var connection = new WebSocket('wss://' + host + ':' + port);

[es128]

The plugin runs its own websocket server, so for this to work you'd need to specify a domain (no 0.0.0.0 or localhost), point to a cert/key pair, maybe some other hurdles. This is only meant to be run in a development environment, within which you could hopefully disable TLS/SSL on your local dev server.

Closing as wontfix, but PR welcome if someone can provide a reasonable solution.

[paulmillr]

not wontfix since we want this...let's keep open — maybe someone would send a pr

[es128]

@paulmillr this is something you want for your own use?

[paulmillr]

yep. we need to have the same SSL-enabled environment on both dev / prod because there may be different behaviours

[es128]

Do you have it set up as a node server configured as the custom server for brunch? I was thinking the most straightforward way to do this would be to attach the ws server to the existing http server handle when available instead of starting a separate one.

[paulmillr]

We have nginx on dev machines :(

attaching ws server to the existing http server handle when available instead of starting a separate one

hmm is this really possible?

[es128]

Yes, definitely. I do something similar in a production app. Just pass ws a server object

https://github.com/einaros/ws/blob/master/doc/ws.md

So nginx terminates your ssl, but a node server run with brunch w -s is behind that? If that's the case, this method could work.

[paulmillr]

No node, nginx + sinatra

[paulmillr]

how about simply specifying a cert path for now?

[es128]

Cert + key + domain. Can't be a self signed cert, generally needs to come from a CA unless you're going to install your custom CA + intermediate into each browser you want to use this with. And you'd also need to rig your hosts file to make sure the domain you're using (which matches the cert) points to localhost. Browser websocket connection fails silently if any of the ssl stuff is not just right.

The reason I've been resisting this is b/c all that isn't the type of thing I want to be helping people debug over gh issues.

I think you can get away with more ssl weirdness on an http server (self-signed, etc) and once you click past the browser warning, the websockets to that same server may be allowed as well.

[paulmillr]

the websockets to that same server may be allowed as well

nope, they aren't

we're using self-signed cert in dev env

[es128]

You've tried? I'm saying that if the websocket server binds to a web server with a self-signed cert, and then you click through the browser security warning, then the websockets may be allowed as well. But I haven't tried, so I'm not sure. Maybe I'll experiment with this sometime soon.

I do know that if the websocket server runs independently with a self-signed cert, then the browser rejects it.

[clarknelson]

asking for this again, sorry! the error on my https sites is quite annoying