[Question] Running behind reverse-proxy with non-standard port

[gorucci]

Pre-work

• I have read the docs.
• I have searched open and closed issues.
• I agree to follow this project's Code of Conduct.

Description

I was successfully running a speediest-tracker for almost a year (via docker compose with linuxserver's swag reverse proxy).

Now I want to deploy it on another node behind a reverse proxy. The neat part is -- this reverse proxy has a non-standard port (let's say 12345). So when I access the app via https://speedtest-tracker.swag-url:12345 the page tries to download css and js files from https://speedtest-tracker.swag-url without a port (https://speedtest-tracker.swag-url/css/filament/forms/forms.css?v=3.3.34.0 for one). Which renders it broken.

My experiments with specifying the full path via APP_URL or ASSET_URL didn't help and rendered the app unreachable (perhaps because of an infinite "proxy-pass" loop, but I could be wrong).

Also, quick googling showed that this is kinda typical issue with laravel's url(), but I'm not familiar with PHP.

Expected Behavior

Urls constructed with "correct" port.

Steps to Reproduce

1. Deploy reverse-proxy with non-standard port (12345).
2. Deploy speedtest-tracker behind it.
3. Open https://speedtest-tracker.revproxydomain:12345.
4. Constructed urls don't contain port in path, and the app is kinda broken.

Deployment Environment

Docker Compose

Application Information

Unfortunately I wasn't able to run it inside my container. Container image is `lscr.io/linuxserver/speedtest-tracker:amd64-1.6.6`.

What browser(s) are you seeing the problem on?

Safari

Logs

[gorucci]

Also, this thread suggests adding X-Forwarded-Port header. I've checked, and swag already has it.

[alexjustesen]

Just to be clear, when you tried the full path you added the port to the end?

[gorucci]

Just to be clear, when you tried the full path you added the port to the end?

When I tried what exactly?

[svenvg93]

Alex means that when you set the APP_URL and ASSET_URL, You set the URL to https://speedtest-tracker.swag-url:12345. As well you need to set them both for it to work.

[gorucci]

when you set the APP_URL and ASSET_URL, You set the URL to https://speedtest-tracker.swag-url:12345.

Yeah, I set it with port.

As well you need to set them both for it to work.

I didn't set them both. I've tried it right now. SWAG dashboard shows that http://speedtest-tracker:80/ is available. When I open https://speedtest-tracker.swag-url:12345 there is a redirect to https://speedtest-tracker.swag-url/admin/login (without port) and nothing is shown. I've also tried this in Private window.

---

On second thought, it is not how it was described below. Never mind it.
I can be totally wrong, but I assume that the values of APP_URL/ASSET_URL are used as prefixes for all pages/resources (instead of the current window url or, better said, the request's url).

If it is, then I don't understand how it is supposed to work with a reverse proxy, as a reverse proxy will access the app with links that point to the reverse proxy itself, thus creating an infinite "proxy-pass loop" (at least it has to be true for resources).

[alexjustesen]

This seems more like a proxy issue than an app issue, I'm going to make this a discussion in case anyone in the community can assist you.

[gorucci]

proxy issue than an app issue

Well, redirecting to the /admin/login without a port doesn't seem like a reverse proxy issue to me.

[gorucci]

I performed another test. I've mapped the port of the speedtest container so it can be accessible without the reverse proxy. I've also removed APP_URL and ASSET_URL. Then authorised in the gui and got the auth cookie.

I then re-enabled APP_URL and ASSET_URL and made a curl with the cookie to https://speedtest-tracker.swag-url:12345. It returned a page with a redirect to https://speedtest-tracker.swag-url/getting-started (without a port). Curling the getting started page returns the page with the correct resources urls. But actions/hrefs for the pages are missing ports.

From the doc itself -- APP_URL used for links in emails and notifications. So it doesn't really apply to my issue (or the doc should be updated).

I've also tried to disable ASSET_URL afterwards. In this case resources also lose a port.

To sum up:
APP_URL does make sense. Because notifications and email can have only one url.
All other links in the app itself should be calculated from the browser window's url and ASSET_URL is just a workaround.

[gorucci]

There is the same issue. Which has been closed without actually being resolved 🤦.