AzuraCast / AzuraCast

A self-hosted web radio management suite, including turnkey installer tools for the full radio software stack and a modern, easy-to-use web app to manage your stations.
https://www.azuracast.com/
GNU Affero General Public License v3.0
3.02k stars 562 forks source link

Stream URL is rewritten #2380

Open AmsterdamFM opened 4 years ago

AmsterdamFM commented 4 years ago

Using Docker installation method

Yes

Host Operating System

Ubuntu 18.04.3 LTS (GNU/Linux 5.3.0-26-generic x86_64)

Describe the bug

URL of our Remote Relay is rewritten from http to https. This happens on the public page and when pressing the play button under Streams in the backend.

To Reproduce

  1. Create a remote relay that uses http.
  2. Use full https in Azuracast 3 Click the play button in the back end or on listen to the stream on the front end.

Expected behavior

Azuracast not modifying the URL of the external stream.

Relevant Logs

In the browser console:

amsterdamfm.mm-stream.nl:8093/azuratest:1 GET https://amsterdamfm.mm-stream.nl:8093/azuratest net::ERR_CONNECTION_CLOSED profile:1 Uncaught (in promise) DOMException: Failed to load because no supported source was found.

Screenshots

Device(s):

Additional context

Directly visiting the URL works But embedded it does not work.

BusterNeece commented 4 years ago

@AmsterdamFM While I definitely understand how this may cause problems when the main AzuraCast installation is secure and the relays aren't, the alternative if we don't do this is that most browsers wouldn't allow you to listen to that relay from within the app because it would be a mixed-content "insecure content on a secure page" situation.

I'm still classifying this as a bug due to it being unexpected behavior, but I'm not sure that it merits any changes in our assumptions, because if we have to choose between having defaults that may overly promote security and defaults that may lead to insecure content being on secure pages, we should prefer the former.

AmsterdamFM commented 4 years ago

You are absolutely right! Maybe there should be a warning in the backend when secure and non secure are mixed.

We are going to see if we can get the stream secured with our host.

novus213 commented 4 years ago

Up , bug confirmed too !