Feature Request: Relative path for reverse proxy setup

[cavebeat]

I have my Grocy now on ubuntu18.04/nginx running on http/80 default-vhost.

It's locally available on http://grocy.mydomain.lan or http://192.168.1.105 or http://sub.mydomain.local and it works.

I do my SSL Termination with HAproxy on https://grocy.mydomain.tld. LETS Certificate with an ALT is already created and working. Grocy is shown.

But now it looks broken. All links are available like "http://grocy.mydomain.tld/node_modules/bootstrap/dist/css/bootstrap.min.css?v=1.18.1" rel="stylesheet">
Blocked loading mixed active content <-- or something like this.

Is it possible to have relative paths to use both, http for internal use and https for external usage?

The ampache project is having a similar problem with absolute/relative paths. ampache/ampache#181

I'm aware i could use a self-signed or any snakeoil certificate to run my local grocy also behind https/443:grocy.mydomain.lan , so the reverse proxy would just show and serve https://grocy.mydomin.tld and my browser wouldn't find a mixed content problem.

If it's possible to have relative paths, or to select "http/https" in absolute paths would be a nice option and feature.

[berrnd]

The URLs are created here - also see the BASE_URL setting in config.php. And yes, it's currently not possible to have it to run on both protocols at the same time.

Some thoughts on this:

• As suggested in the referenced ampache issue, you could just rewrite alle the URLs in the HTTP response (don't know if HAProxy can do this)
• You could add a header X-Forwarded-Proto in HAProxy for example (which is pretty standard I think) and I could extend the URL manager to respect this
• I personally run grocy and many other apps in the same way and use "Split-horizon DNS" for everything, so internal traffic stays internal but I can always use the same host name to access the application

Let me know if I should add the second suggested point.

[cavebeat]

hmm,

atm i already have a X-Forwarded-Proto header set in my config.

http-request add-header X-Forwarded-Proto https

I've set now the base url to https://grocy.mydomain.tld and it works now on my haproxy. As i do not have the need to use it with https from local-subnet. So i'm happy.
Maybe i'll update my local DNS to have a split-DNS for grocy.mydomain.tld point to my local haproxy ip from local.

If you could add option nr. 2 easily, that would be nice of course. Probably also for future users useful. Depends on your time and the amount of work for you.

Thanks

[berrnd]

But when you set BASE_URL to https://grocy.mydomain.tld and when you access grocy from http://192.168.1.105 all URLs will point to https://grocy.mydomain.tld, or not?

I will rethink this, theoretically also relative URLs should work, I don't remember exactly, but there was a problem with something, that's why I added to always use absolute URLs for everything...

[cavebeat]

But when you set BASE_URL to https://grocy.mydomain.tld and when you access grocy from http://192.168.1.105 all URLs will point to https://grocy.mydomain.tld, or not? <= Yes, i'll have to use https://grocy.mydomain.tld but thats not a problem. as there is no load or bandwidth problem caused by grocy.

I'll check 27daf38
thx

[berrnd]

That's right, but when you leave BASE_URL set to default /, then the current hostname is used - now while respecting the X-Forwarded-Proto header - have tested this myself (for this time :D), works as long as you don't have grocy's base in a subdirectory...

[SeubertE]

A quick note that I don't know if already exists or belongs somewhere else, but for those using Apache as the reverse proxy instead of Nginx, you should do three things:

1. sudo a2enmod headers
2. Add RequestHeader set X-Forwarded-Proto https to your .conf
3. sudo systemctl reload apache2

[martin-braun]

I use HAProxy on pfSense and face the same issue using nginx. Setting BASE_URL to https://grocy.example.org/ did the trick for me. If the links would really just start with / the browser should point to the right path, since window.location.href starts with https as well. I guess those links are build as absolute links or am I missing something? This error doesn't need to occur, if this was addressed, but not big of a deal.

[berrnd]

Setting BASE_URL to https://grocy.example.org/ did the trick for me.

Leaving BASE_URL at its default / just means "auto guess the root", which works for almost all cases pretty well. For any other kind of special setup I don't think it's a real problem to just set it to the proper root URL, which is what you did.