Your browser was unable to load all of the resources. They may have been blocked by your firewall, proxy or browser configuration.
Press Ctrl+F5 or Ctrl+Shift+R to have your browser try again.

snapcast handling #56

#1

Hi,

i just did an upgrade for my installation from 1.48 to 1.54. Snapcast playback still works, but the snapcast control in RompR is no longer accessible. My snapcast installation has HTTP/jsonrpc enabled, but RompR states that the snapcast server isnt rechable. So i did some digging - the outcome is kind of unique to my setup, and not neccesarily a bug.

I understand that for versions > 1.48, calls to snapcast are handled directly from the browser via js/websockets. Previously, snapcast calls were made server-side. This breaks setups where the snapcast webservice is not accessible directly from the client - for example when RompR is exposed externally via a reverse proxy, but snapcast isnt (or just listens to localhost). There are ways around that by exposing snapcast websockets externally, but perhaps there is a more elegant solution to that.

The other issue i've encountered is that when RompR is served securely via SSL/TLS enabled webserver, connectivity to snapcast is denied by browsers, because the websocket connection is not secured (ws:// instead of wss://). In the browser JS console, the exception "Uncaught (in promise) DOMException: The operation is insecure." is shown.

I hope this makes sense.

Thanks!

Christian

  • replies 2
  • views 2K
  • likes 0
#2

Yeah that does make sense. There is no elegant solution. I take the attitude that people who know how to set up a reverse proxy know to fix other connectivity issues that causes. It's intended for use on a local network and the setup is described such that it works for most people.

Serving Rompr over SSL/TLS is NOT supported and will not work properly, not just with snapcast. I've not checked if snapcast even supports a wss: connection. Browser security cannot be circumvented, I do most stuff server side to get round it but websockets work so much better and I'm moving stuff over to use those wherever I can.

Loopback666 · Author
#3

Thanks Mark.

I wasnt aware of the LAN-focussed design aspect, even for application control. Makes no sense to work around this every time there is an update, for a feature that i rarely need. :-)

For the curious and desperate, secure websockets can be done with nginx in front of snapserver.