Currently the JS blindly tries to connect to 'ws://' + window.location.hostname + ':81', but if you have an HTTPS proxy in front of the management page, this breaks for a couple reasons -
- The browser will not let a page loaded via HTTPS use an insecure WebSocket, so the scheme needs to be
wss://in the event that the browser is connecting to an HTTPS URI - The proxy is probably listening on different ports, so hardcoding 81 is pretty inflexible
For the ws:// scheme, detecting the original scheme and dynamically using wss:// where appropriate is pretty doable given that the JS can see the actual scheme in use.
The port is a bit trickier, but some options that come to mind:
- Just increment the port JS sees as being connected to by one
- Have the WebSocket API available on the main port
- Allow setting of the WebSocket port or entire URI via a client header - There’s security dragons here given a proxy not configured with that header will pass the header through directly from the client, but given one would be insane to not have auth on the proxy, it’s probably not a big deal
- Add the ability to connect to arbitrary WebSocket URIs exposed in the UI, with the last used URI saved in a cookie or something so it can still auto-connect
For reference, I’m attempting to put a Pixelblaze pico+ behind pomerium so I can safely expose it to the internet