0

I have a centos server that is running httpd. I have a site at staging.example.com I then have staging.example.com/blog or staging.example.com/wiki. I am working on the blog part. That is a wordpress install. If you go to staging.example.com/blog it goes to blog/wp-admin/setup-config.php if you try to type in staging.example.com/blog/wp-admin it redirects to staging.example.com/wp-admin if you follow the link to install wordpress it goes to staging.example.com/blog/wp-admin/core/core/core/core/core/core/core/core/core/core/core/core/core/core/core/core/core/core/core/core/core/install.php

I have staging.example.com at /var/ww/html/example.com the blog is at /var/www/html/blog wiki is at /var/www/html/w

Here is my domain specific config:

NameVirtualHost staging.example.com:80
<VirtualHost *:80>
        ServerName staging.example.com
        ServerAlias staging.example.com
        DocumentRoot /var/www/html/example.com
        RewriteEngine On
        RewriteCond %{HTTPS} off
        RewriteRule (.*) https://%{SERVER_NAME}$1 [R,L]
</VirtualHost>

NameVirtualHost staging.example.com:443
<VirtualHost *:443>  
        ServerName staging.example.com
        ServerAlias staging.example.com
        DocumentRoot /var/www/html/example.com
        ErrorLog /var/log/httpd/example.com/error_log
        CustomLog /var/log/httpd/example.com/requests.log combined

        ProxyPreserveHost On
        ProxyPass /blog http://localhost:8443
        ProxyPass /wiki http://localhost:8444
#           RewriteEngine On
</VirtualHost>

NameVirtualHost localhost:8443
<VirtualHost 127.0.0.1:8443>
        DocumentRoot /var/www/html/blog
        ErrorLog /var/log/httpd/example.com/blog/error_log
        CustomLog /var/log/httpd/example.com/blog/requests.log combined
</VirtualHost>

NameVirtualHost localhost:8444
<VirtualHost 127.0.0.1:8444>
        DocumentRoot /var/www/html/w
        ErrorLog /var/log/httpd/example.com/wiki/error_log
        CustomLog /var/log/httpd/example.com/wiki/requests.log combined
</VirtualHost>

What is causing that?

1 Answer 1

0

Although there are ways to do it either way, I find things to go much smoother when the path (request URI) seen by the reverse proxy is the same as that seen by the origin. That way, if the code on the origin wants to easily generate URLs (in HTML, in redirects, etc.) that work, it's able to generate them perfectly without fuss simply based on the local REQUEST_URI (and HTTP_HOST that gets passed in thanks to ProxyPreserveHost, in the case of absolute URLs). If instead the reverse proxy is introducing a path segment such as blog, you have to take special steps to let Wordpress know to inject blog into URLs it writes, and in doing so, the URLs only work via the reverse proxy (debugging without the reverse proxy is then problematic).

So instead of ProxyPass /blog http://localhost:8443, use ProxyPass /blog http://localhost:8443/blog on the reverse proxy, and that means on your origin server (the <VirtualHost 127.0.0.1:8443>) you need to have the blog directory be a child of the DocumentRoot rather than be the DocumentRoot. For example, make a new directory at /var/www/html/wp and then move your blog directory inside the new wp directory and set DocumentRoot /var/www/html/wp. Same goes for the wiki. Now you're at a point where $wgServer and $wgScriptPath and the WordPress equivalents actually behave as expected.

You're also going to be playing the same game with the fact that you terminate TLS at the reverse proxy such that the end user sees URLs starting with https:// while the code on the origin sees the HTTPS variable unset. This is a bit easier to overcome though, and it's better to deal with this and keep it that way, than to stack TLS latency by doing a ProxyPass https://.... Basically you'll need your reverse proxy to add an HTTP header along the lines of X-Forwarded-Proto: https in all the requests it makes to the origin, and then you'll need your code (Wordpress and wiki) to watch for this header and write absolute URLs with https://... when that's present. Or skip that and have wp+wiki always write URLs with https://, given your RewriteRule. If you don't do one of these, you'll probably see a slew of mixed-content errors, e.g., no CSS.

4
  • So would blog.virtualzone.de/2016/08/… be what you are talking about? Why do I need to move the blog directory inside of something like /var/www/html/wp?
    – user340594
    Jul 20, 2017 at 19:43
  • Yes, that is what my third paragraph is talking about. But keep in mind that's a separate yet loosely related issue from the path problems you asked about and that my first two paragraphs offer a solution to. You don't have to move the blog directory inside /var/www/html/wp but if you don't, you need to back your DocumentRoot up a level to /var/www/html. That would also be fine, except for the fact that now your origin is serving a lot more than exclusively the blog! Even if your origin is locked down from the world and only answers to the reverse proxy, traversal bugs make it unwise.
    – yeahforbes
    Jul 20, 2017 at 20:49
  • when I change localhost:8443 to localhost:8443/blog I get a 404 error. If change the document root to /var/ww/html how would example.com/blog be served out of /var/ww/html/blog? Why is /blog being deleted from example.com/blog/wp-admin? It seems like it is still looking inside the /var/www/html/example.com directory instead of /var/ww/html/blog.
    – user340594
    Jul 20, 2017 at 22:40
  • I found httpd.apache.org/docs/2.4/urlmapping.html which states that absolute paths break out of the proxy part and just serve it off of the main document root for example.com instead of example.com/blog.
    – user340594
    Jul 21, 2017 at 15:23

You must log in to answer this question.