Cover Art URI schema

[cuthulino]

Describe the bug
I am serving snapweb with an reverse proxy to get https.
The frontend and all controls are working as desired.

But the coverart does not work.

To me it looks like it is hardcoded to load http://<hostname_from_config>:1780.
For my config this would be correct: https://<hostname_from_config>.

It would be great, to get an additional config, to configure the cover art url.
Or even better, build the url dependen on the url the UI is loaded.

Steps to Reproduce

1. Serve Snapweb via reverse Proxy with https
2. Open Snapweb and Dev-Console
3. See logs in console

Environment details

• OS: debian
• Snapcast version: 0.28.0
• Installed from .deb package

Attach logfile if applicable

[badaix]

Related to #1139

[badaix]

FYI: the tls branch supports HTTPS out of the box. If you want to test it, you can use a snapshot from the CI built: https://github.com/badaix/snapcast/actions/runs/9043310893

The snapserver.conf has a new section ssl, where you have to configure your certificate and key:

# Secure Socket Layer #########################################################
#
[ssl]
# https://deliciousbrains.com/ssl-certificate-authority-for-local-https-development/
# https://gist.github.com/fntlnz/cf14feb5a46b2eda428e000157447309

# Certificate file in PEM format
# certificate = 

# Private key file in PEM format
# private_key = 

# Password for decryption of the private_key (only needed for encrypted private_key file)
# key_password =

#
###############################################################################

And ssl_enabled must be set to true in the HTTP settings:

# HTTP RPC ####################################################################
#
[http]
# enable HTTP Json RPC (HTTP POST and websockets)
#enabled = true

# address to listen on, can be specified multiple times
# use "0.0.0.0" to bind to any IPv4 address or :: to bind to any IPv6 address
# or "127.0.0.1" or "::1" to bind to localhost IPv4 or IPv6, respectively
# use the address of a specific network interface to just listen to and accept
# connections from that interface
#bind_to_address = 0.0.0.0

# which port the server should listen to
#port = 1780

# enable HTTPS Json RPC (HTTPS POST and ssl websockets)
# ssl_enabled = false

# same as 'bind_to_address' but for SSL
# ssl_bind_to_address = 0.0.0.0

# same as 'port' but for SSL
# ssl_port = 1788

# serve a website from the doc_root location
# disabled if commented or empty
doc_root = /usr/share/snapserver/snapweb

# Hostname or IP under which clients can reach this host
# used to serve cached cover art
# use <hostname> as placeholder for your actual host name  
#host = <hostname>

#
###############################################################################

This is still work in progress, but I'm already using it and it's nice to see that Snapweb can be installed as PWA now, where the page is served via HTTPS.

[quite]

The tls branch is a nice development! My specific use-case: to be able to generally access snapserver (and other services) on my home LAN over TLS, I'm fronting it with a reverse-proxy and automatic certs for TLS (Caddy) on the public IP my ISP gives me. My router does some hairpinning, so accessing the reverse-proxy never actually leaves the LAN (and Caddy will return HTTP 403 if the client IP is not on my RFC1918 network).

Thing is, I prefer to reverse-proxy these services on specific URL paths, rather than a new subdomain for each. This demands that the service uses relative references to all of its sources, or that it can be told the full URI where it is being hosted. So I think the url_prefix will be helpful here. But I wonder, does it also deal with the websocket? I didn't see anything after a quick look at the code. I tried earlier quickly to serve snapserver 0.29 (not the tls branch) behind the reverse-proxy in the above manner, and it seems that the web frontend wanted to connect to the websocket as wss://services.example.com/ (the FQDN I use)

[gitisz]

Thought I would try the TLS branch but I cant seem to find and packages or be able to build it locally. Any idea when we are planning to merge and release?