we are running a Debian box with a reverse proxy setup behind which one of my users is trying to setup a Kirby installation. I’ve now started dabbling with it myself and quickly found out that to make Kirby itself work I only needed to do
c::set('url', '...');
and all was well. Unfortunately, that doesn’t go for the Panel. It will load forever and then finally the URL will have the inner web server’s port appended (which is firewalled off for access from the outside) and the page will of course fail to load. I’m suspecting that the base URL needs to be set in a second place for the panel to make use of it, but can’t figure out where that place should be. Any help appreciated!
The issue seems to be similar to this one. Bastian also included a possible fix at the end, please check if that helps. The issue will be fixed in the next Kirby release.
Thank you for the reply, Lukas! I made the changes suggested by Bastian in panel/app/controllers/views/auth.php (it’s lines 8 and 31 btw, not 8 and 30). Unfortunately, after loading for about a minute, I now get redirected to “/”. I agree that my issue looks similar to the one you linked to, but perhaps it’s not the exact same problem?
My suggestion for reverse proxy setups is mod_rpaf. If you get it to work, that’s the cleanest solution you can get and it will work for any PHP software, not just Kirby.
I realise we’re leaving the area of where this has anything to do with Kirby, but is mod_rpaf something that would run on the inner Apache? Because on the outer layer we’re on Lighttpd and planning on switching to Nginx, not Apache…
Yes, that would be installed for the inner Apache (the one behind the proxy). The proxy itself only needs to set the X-Forwarded-* request headers (especially X-Forwarded-Port and X-Forwarded-Host), no matter which software is used as reverse proxy. mod_rpaf then converts these values to the actual env variables for PHP.
Non the less, thanks.