Crystal: Allow Playground to use WSS WebSocket when served over HTTPS

[opiation]

On version 0.24.1, the Crystal playground does not use a secure web socket when the playground is served over HTTPS. Modern browsers generally disallow connecting to an insecure web socket when the page is served over HTTPS rendering the playground mostly unusable.

To reproduce this, serve the playground behind a proxy that forces SSL like nginx. When the playground loads, new WebSocket("ws://" + location.host + "/client"); will fail throwing a SecurityError.

Granted, the playground may not have been intended to be used in such a way but perhaps checking the protocol in session.js could be a lightweight solution to work over HTTPS without changing much of anything else.

Where

this.ws = new WebSocket("ws://" + location.host + "/client");

becomes

var socketProtocol = location.protocol === "https:" ? "wss:" : "ws:";
this.ws = new WebSocket(socketProtocol + "//" + location.host + "/client");

This small change worked for me. I'm happy for someone else to submit the PR and get the cred though. Cheers.

Crystal version

> crystal --version
Crystal 0.24.1 (2017-12-22)

LLVM: 4.0.0
Default target: x86_64-unknown-linux-gnu

[asterite]

The whole compiler is compiled without openssl support. So the playground will never work with https unless we also compile openssl with it.

I tried to do it once with omnibus but it was a mess and I wasn't able to do it.

[opiation]

I see. I assume this was to with trying to get the playground itself to serve over HTTPS? I ask because I'm serving it over HTTP within a docker container and running an Nginx proxy in front to handle the SSL handshake. The only thing missing was that the front end wasn't using wss when over HTTPS.

With the proposed change, the playground could support the HTTPS setup I'm using without the need to compile with openssl. Basically, just let the devs figure out the SSL proxying and _support_ it only to use wss instead of ws when the front end is served over HTTPS.

This way, no need to fully support openssl but still use a secure socket if HTTPS is detected, assuming the developer set up their proxy correctly. Would that be a fair compromise rather than full openssl?

[asterite]

I'm not sure I understand, but the compiler's binary doesn't support https nor wss nor anything that is related to openssl. I also don't know why the playground needs to run over https if it's just a local utility.

[opiation]

Apologies for leaving out some context. I'm not running as a local utility. I'm using it, more specifically its workbooks, in the work place as in internal service with examples specific to our company which requires all tools served over HTTPS. As such, I'm running it on a server behind nginx to handle HTTPS so other users can easily play with crystal (without installing it) and explore the company-specific workbooks which is perfect for guided learning. By having the front-end use wss or ws depending on the protocol it's served from, this allows the front-end to work just as it does now by default and also support secure sockets if HTTPS is detected.

I hope I've clarified my use case. While I understand its primary purpose is for local usage, it can be bound to 0.0.0.0 making it really useful as a lightweight, presentation/teaching tool with which students can interact. If such a use case does not align with the project's goals, feel free to close this issue.

For anyone else stumbling into this issue attempting something similar, the code change in my first comment is all that's needed to serve the playground over HTTPS with an appropriate proxy setup.

[asterite]

Ooooooooooh... nice use case! Sorry, I read too quickly your original post and didn't see it includes a fix 😊

[straight-shoota]

Sounds totally legit. Would you put that change in a PR?

[asterite]

Is this fixed by https://github.com/crystal-lang/crystal/pull/5527 ?