OS X Server versions 5.0.3 and above configure Apache as a reverse proxy - it serves its websites on separate instances running on different ports. The main proxy answers on the usual ports 80 and 443, and then redirects the request to the appropriate instance, based on the domain requested, but on a different port: either 34580 (normal) or 34543 (SSL). This means, that when accessing the website and requesting site resources, the requests must always come via the usual port 80. Internally, however, the site is answering on port 34580. This is causing MAJOR hassles with Kirby, and I cannot solve it.
First problem: all Kirby functions that generate URLs automatically - such as url(), css(), js(), or thumb->url(), create URLs that automatically append the “:34580” port to the server name - i.e., “http://example.com:34580/assets/mypic.jpg” instead of simply “http://example.com/assets/mypic.jpg”. Php is recognising the address of the virtual host in its proxied Apache instance as the ‘real’ address. This means that none of these resources will load - the user browser is trying to access these resources from outside on port 34580, and the server will only respond on port 80.
That can be overcome - with great effort - by using ‘str_replace()’ to strip out every occurrence of “:34580” from the outputted string of every Kirby URL function. It’s a chore, but it works sufficiently well on templates and snippets. But not on the panel…
Second problem: the panel does not load at all. When I try to access the panel at “http://example.com/panel”, I get automatically redirected to “http://example.com:34580/panel/login”. Again, because the request is coming from outside, it must come on port 80, or it will be ignored. The panel never loads. There is no way that I can apply str_replace() to every corner of the panel…
Does anyone have any suggestion? Is there a way to deploy Kirby on the current version of OS X Server? Any and all guidance would be enormously appreciated.
The problem is that PHP doesn’t recognize that its Apache sits behind a reverse proxy.
Could you please check if the “reverse proxy Apache” sets the X-Forwarded-Port request header (by using var_dump($_SERVER['HTTP_X_FORWARDED_PORT']);)?
If it does, that’s a great first step. You then need Apache’s mod_rpaf for the inner Apache to register this hostname and port so that PHP sees the correct port. If you want, I can help you with that.
@lukasbestle: indeed, the reverse-proxy instance does set both HTTP_X_FORWARDED_HOST and HTTP_X_FORWARDED_PORT (=“80”).
I just did a “print_r(apache_get_modules())”, and “mod_rpaf” is not on the list…
I’m scared of trying to install a custom Apache module into OS X Server. I know Apple has a very peculiar way of setting things up on the Server - as we can see - and I’m afraid of disrupting existing services, or possibly causing issues for future upgrades…
Maybe there is a different way to look at this problem.
Kirby is being very clever, and building the URLs automatically, based on a ‘base url’ provided by $_SERVER[] info - I’m guessing, haven’t looked at the code. That would be suitable for most use-cases, but there will always be the exceptions - like the current one - where it would actually be more helpful if we could set the ‘base url’ for the site manually - perhaps in a config.
Does such a config already exist? - could it be easily implemented?..
mod_rpaf is a third-party open-source module. It is the (in my opinion) best solution of implementing a reverse proxy and I’m shocked that Apple didn’t include it or a similar solution by default.
But generally I would recommend using your own Apache behind the reverse proxy (you can also install Apache using Homebrew). This makes sure that no changes are overwritten. I haven’t used OS X Server for a while, so I don’t know if it is possible to manually configure the reverse proxy.
But while this would be the proper solution, I know that it is quite complicated and difficult to setup.
You can try using the url option in Kirby. Maybe this can already solve the issue.
I have two sites, one which is at the root-level of the domain, and one is in a sub-folder.
I set the url option for the one that is in a sub-folder - i.e.; http://example.com/mysite - and everything works just fine.
When I set the url option for the site that is at root level - i.e., http://mysite.com - the frontend loads without any problems, but I’m getting a ‘page not found’ error when trying to access the panel - that is: trying to access http://mysite.com/panel/ gives me a 404 error… Could this be a bug in the URL option?
Any hints or suggestions would be greatly appreciated.
I’m being redirected: Kirby automatically redirects http://mysite.com/panel/ to http://mysite.com/panel/login.
The 404 error comes from not being able to find /panel/login.
Strange thing is, it does find it if the whole site is in a sub-directory.
EDIT
When Kirby is located in a sub-directory, it does find the login page. But trying to login actually fails: the ‘login’ button is automatically forwarding me to port 34580 - it seems the panel is ignoring the custom-set url option.
So, it doesn’t seem to work, even if Kirby is in a sub-directory…
It does seem as if it is ignoring the custom url option. Could this be a bug?
@lukasbestle: thank you very much for your input and suggestions.
The .htaccess file on both sites was exactly as provided in the Kirby standard download - none of the RewriteRules had been changed. The rewrite rules in the Panel block are uncommented, and they should be working, just like the others… Is there a specific way to test?
I’ve now uncommented the RewriteBase rule in the .htaccess of the site that is located in a sub-directory of the domain, but there was no improvement. Also, I suspect this is not the issue, as the panel was working before the upgrade to Server 5 - the client had already been using the panel and entering lots of content. Adding the 2 lines you suggested to the panel index.php file also made no difference, unfortunately.
The site that is located at the domain root-level - i.e., at http://mysite.com - also still doesn’t work, even after adding the lines into the panel’s index.php…
Hm, that’s difficult to say, because this issue is not related to the reverse proxy setup and I didn’t have any problems with Panel rewriting so far.
The two lines I posted are to solve the Panel login issue (so that the Panel recognizes your custom URL in the configuration). So this change can only solve the issue with the site in a sub-directory.
@lukasbestle, thank you for your all your assistance and suggestions. I’ve now contacted Kirby Support, and am waiting to hear back. In the meantime, should you have any further ideas, please do not hesitate to put them here. I’m willing to try anything!
Just a quick note to let those interested know, that @bastianallgeier was (as usual) extremely helpful and efficient, and managed to pinpoint - and solve - the issue. I believe that the next Kirby update will have a fix/workaround for this.
So just in case someone is running into this again. In the current version (2.1.1) there only needs to be a small change made to the auth controller. (panel/app/controllers/views/auth.php) In line 8 and line 30 change:
You wrote in the other topic that the site is hosted at HostGator. They much likely don’t use OS X, so this issue doesn’t apply here. Also it has been fixed in Kirby.
