Azuracast: Using non standard ports not supported on every features

[user171]

Using Docker installation method

Yes
Host Operating System

Arch Linux
Describe the bug

I have changed the standard port as explained in the doc for docker. That works fine. (I have a web server running on that host as a companion for the radio and it needs ports 80 and 443, so I gave Azuracast ports 81 and 444.) The web UI opens just fine on port 444 but then some automatically generated URLs do not take the port into account. For example in the control panel of the station, the generated streams URL do have the port present in the URL, but the generated URL for Administration URL lacks the port. I can still click on it, that won't work, and then I edit it in the browser bar to add the port and then it loads properly. The workaround is pretty easy. The problem arises with Web DJ. There is a function in there that takes the URL of the server to connect to it. It's in the section called props and I can clearly see the port is missing. And sure enough if I click "start streaming" I can see an error message in the console log that says the browser can't establish a connection to the server at wss://server-url-without-port/radio/8005.
To workaround that would require a bit more fiddling with editing the code and re-executing the scripts. Something I can't really explain to a non-tech user.
I don't know if I did something wrong but I followed the doc and could not find anything else to set in the admin panel. And the fact that the URLs generated automatically within the app inconsistently take into account the port in some cases make me think it could be just that some parts of the code forget to use the modified port.
To Reproduce

Expected behavior

Relevant Logs

Screenshots

Device(s):

• Device:
• OS:
• Browser:
• Version:

Additional context

[user171]

By the way, on a completely unrelated note, thanks a lot for the great work. I find the project very well developed and documented. I'm having a great time installing, configuring and using it.

[ogrenci01]

Hi @user171 ;

The explanation about the subject is clearly stated for both installation methods. Please check it:

Docker: https://www.azuracast.com/help/docker/#use-non-standard-ports

Ansible: https://www.azuracast.com/help/ansible/#use-non-standard-ports

You need to customize the Nginx configuration. We definitely do not recommend this.

Ref for Docker: https://www.azuracast.com/extending/modifying_docker.html#common-examples

You can browse similar topic to use custom ports: #2430 #2501

[user171]

Thanks for your update @ogrenci01. As stated above, I had followed the doc you mention here and that worked just fine. I also don't think it is related to the issues listed above.
Maybe I did not explain myself properly in the first message, so, just to make sure we talk about the same thing here, let me try to rephrase:

When I log in Azuracast I am presented with a dashboard. In the Station Overview, in the first station, I click Manage and that opens the Profile page for that station.
There, I can see Streams with a list of streams for that station. In the form of https://example.com/radio/8000/128?1587061607. So far so good.
Now say I follow the doc to use non standard ports for docker, I modify the .env file with

AZURACAST_HTTP_PORT=81
AZURACAST_HTTPS_PORT=444

Then when I go back to the same station profile, in Streams I can see the URL has been updated to https://example.com:444/radio/8000/128?1587061607 (note the :444 that corresponds to the new port in the .env.
This is the expected behaviour, it works perfectly.

The problem is, this behaviour is not applied consistently across all the app.

As an example, just below the Streams list, I can see the Broadcasting Service that presents the Administration URL as being https://example.com/radio/8000/admin.html. This URL is wrong. It does not take into account the new AZURACAST_HTTPS_PORT from the .env file.
The URL should have been https://example.com:444/radio/8000/admin.html. With the :444 as the port, just like the example for the Streams.

So, in this case this is not a big deal since it is easy to just add manually the :444 in the browser bar when trying to load this wrong URL.
But in the case of the Web DJ web client, the port is also missing in the generated URL and that one is a lot harder to rewrite since it's in the html code.

Does that make sense?

[Vaalyn]

I can reproduce that behaviour in my local dev installation.

It seems like some parts of the application don't take into account that the base URL can have a different port for the web server.

---

For documentation:

From what I can see in the code that generates the URL for the fronend public url this is not taking into account that there is a different port configured.

For the web dj the URL is generated here.

I think we can fix those problems by modifying the getBaseUrl method of the Router to take the port into account.

[user171]

I think I found another place where it occurs, but I'm not entirely sure.

When I go to Streamer/DJ Accounts -> in the listed account -> I click Broadcasts -> the popup shows the recorded broadcasts for that streamer -> I click DELETE on any of those recordings -> I confirm with Delete:
In the browser console I can see: Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://example.com/api/station/1/streamer/1/broadcast/3.

This is the wrong URL. It lacks the :444. (Which is probably what triggers the CORS error).

[user171]

It also happens in the Music Files when I click a file to download it, the port is missing.

[davy39]

Hi, I'm trying to get AzuraCast working on my server. I needed to change default ports because of my apache server already running and serving websites. So I would like to reach it by setting up a reverse proxy with Apache, in order to access it through standards ports (radio.my-site.org). Still few problems with that #2616 ... I'm just wandering if it wouldn't mess up everything if .env custom ports were included by default in urls ? Wouldn't it be better to rely on configuration webui ?

[SlvrEagle23]

@user171 @davy39 @Vaalyn So, I've looked into this, and at least as far as I can tell from my tests, as long as you add the port number to the "Base URL" in the system settings panel, everything else should work just fine.

We could automatically detect the AZURACAST_HTTP_PORT environment variable in setting the default value for that field, though. We don't even need access to that environment variable to do so, though; we just need to factor in a broader portion of the current request URI when the settings page is first accessed (since it will be via that same port).

I will look into implementing that and update shortly.

[SlvrEagle23]

The latest update will use the full request URI as the default value for the base URL, which will properly include port, scheme and other details rather than just the host. This should help significantly with both this issue and a few others we've had with IP address base URLs in the past.

[user171]

I have done the update and tested and can confirm it works. Thanks.