fix: Add DISABLE_HTTPS support for WebSocket URLs in system-config.js

[manohar02]

Fix WebSocket connections when HTTPS is disabled

WebSocket connections were failing when DISABLE_HTTPS=1 because the URLs were hardcoded to use wss://.

This adds support for the DISABLE_HTTPS environment variable so WebSocket URLs use:

• ws:// when HTTPS is disabled
• wss:// when HTTPS is enabled

Changed: Added inline conditionals to system-config.js for protocol selection.

[saghul]

• Fix WebSocket connection failures when DISABLE_HTTPS=1 is set

• WebSocket URLs now use 'ws://' when HTTPS is disabled and 'wss://' when enabled

Please drop any changes other than these 2.

[saghul]

Please change the existing config files to honor the env variable, don't a whole new template logic, that's not acceptable

[manohar02]

@saghul Could you please review this updated implementation? I've addressed your feedback by:

• Modifying the existing system-config.js file instead of creating new templates
• Using inline conditionals for protocol selection rather than duplicate template blocks
• Keeping changes minimal while fixing the WebSocket connection issue when DISABLE_HTTPS=1

Thanks!

[saghul]

Hum, hold on. What use case do you have where the client will connect to WS and not WSS?

WebRTC only works on secure endpoints and you'd be downgrading the connection there wouldn't you?

[manohar02]

@saghul ,

You are right to call that out, but in our case this is an internal setup over VPN, so WS is sufficient. It's not public facing and all traffic stays within the local network. we tried self-signed certs, but they added overhead and introduced some performance cost.

[saghul]

I see. I fear this would break people's systems. I think a better way to go about this is to use the custom-config.js and override the WebSocket URL there.

[manohar02]

@saghul
yeah, don't want to break existing setups. What if we add a new env var like ENABLE_WS_INSECURE=1 to switch to ws? since DISABLE_HTTPS=1 means the page is HTTP, browsers block wss anyway so most people in this setup are already behind a proxy or VPN. This way, we keep it opt-in, no breakage, and avoid custom config mounts just to use ws. trying to keep it simple. what do you think?

[saghul]

The thing is, since you need HTTPS in order for WebRTC to work, why do you insist on using WS? There is already a way to override it.

Your use case is so niche I see no good reason to add a dedicated option for it, when there is already a way to accomplish what you need.

DISABLE_HTTPS=1 is designed for when you are using a reversee proxy, and in that case why are you not proxying the WS connection too?

[manohar02]

Thanks for the clarification, you are absolutely right that DISABLE_HTTPS=1 was designed for reverse proxy setups.
but in internal deployments (VPN/local networks) where security is handled at the network layer. WebRTC works fine over HTTP on private IPs, but currently flipping WSS to WS requires custom config mounts. HTTP + WS works perfectly for WebRTC and the pairing makes sense, while HTTP + WSS seems odd and also goes against Docker philosophy of simple env driven configuration.
Would you be open to adding ENABLE_WS_INSECURE=1 ? It wouldnt affect reverse proxy users at all, but would give internal users a clean Docker style env toggle instead of mount workarounds.

Happy to open a PR if this sounds reasonable.

[saghul]

WebRTC works fine over HTTP on private IPs

Only localhost. Any other origin is deemed not secure.

Would you be open to adding ENABLE_WS_INSECURE=1 ?

No, as you can see, the use case is very narrow.