HTTP:X-Forwarded-Port is not considered about omd

[sni]

The original file is here: https://github.com/ConSol/omd/blob/labs/packages/omd/skel/etc/apache/conf.d/omd.conf

[nils-ballmann]

Okay, my suggested fix is:

--- omd.conf.orig       2018-04-12 17:13:13.159353000 +0200
+++ omd.conf    2018-04-12 17:15:28.680794300 +0200
@@ -12,7 +12,12 @@
 RewriteCond %{HTTPS} =on
 RewriteRule ^/###SITE###/?$ - [env=proto:https]

-RewriteRule ^/###SITE###/?$ %{ENV:proto}://%{SERVER_NAME}:%{SERVER_PORT}/###SITE###/omd/ [R=302]
+RewriteRule ^/###SITE###/?$ - [env=port:%{SERVER_PORT}]
+
+RewriteCond %{HTTP:X-Forwarded-Port} !=""
+RewriteRule ^/###SITE###/?$ - [env=port:%{HTTP:X-Forwarded-Port}]
+
+RewriteRule ^/###SITE###/?$ %{ENV:proto}://%{SERVER_NAME}:%{ENV:port}/###SITE###/omd/ [R=302]

 # Keep original redirect as fallback, rewrite rules do no work in shared apache mode
 RedirectMatch ^/###SITE###$  /###SITE###/omd/

It creates an env var for port with SERVER_PORT as default value and replaces this value with the value from X-Forwarded-Port if there is any. Then this env var is used in the real RewriteRule instead of the SERVER_PORT var.

[sni]

Did you know you can directly edit the file on github and github will create automatically a pull request for that change.

So your setup looks like [Docker host apache] ---reverse proxy---> [docker omd container] where the omd container again has the system apache on 80/443 reverse proxying to the site apache on port 5000?

[nils-ballmann]

No I didn't. Does this creates a full fork on my account?

Its even worse:
Network → gate-apache with reverse proxy and public ssl wrap → server-apache with reverse proxy and internal ssl wrap → docker omd container with exposed port 80 as 127.0.0.1:10080 → container-apache 80 reverse proxy → site-apache on 5000

The multi-site support you built into the docker container is an extra layer I probably don't need.

Normally I run two container on different exposed ports to have a production container and a staging container, so I can take one down without affecting the other. But for the omd container I'm thinking about doing a production site and a staging site inside one container. This makes URL-normalization on the gate- and server-apache way easier and spares (non-public) ports on the server-apache, but looses the independence between the two sites.
Another alternative is to build another container with a different site name for the staging system, but the omd containers with multi-site-support are... heavy.

Best case (for me) would be to have a lightweight single-site-per-container solution, even without SSL for the web-ui.

[sni]

I tried a few things and having a hard time to reproduce any issue here. Who will set the "X-Forwarded-Port" header in your case? Also it's usually a good idea to have either everything ssl or nothing. This remove some possible redirect issues already.

[nils-ballmann]

In my case its the gate-apache. But I think, in the scenario I got here, there is no difference if the server-apache would be setting it.

The main thing is, to not do SSL inside the container, but in the apache on the docker host.

So if I would be testing this, I would take a xenial server vm. Install docker-ce and apache2 in the vm. Run the OMD container in NonSSL mode and wrap SSL in the server vm apache as well as use:

RequestHeader             set X-Forwarded-Proto "https"
RequestHeader             set X-Forwarded-Port "443

The thing is, I run multiple different services in multiple containers, some with SSL and some without. So I have to wrap the SSL on the server apache anyway. Doing it additionally in the container is unnecessary. And I don't have to rebuild the container every time I got a new cert.

Another way to test is, if you run SSL (even in the container) on a non standard SSL-Port. e.g. 10443. Then you definitely need X-Forwarded-Port too. If you consider values from X-Forwarded-Proto you always have to consider values from X-Forwarded-Port too:

• http://domain:80/path
• http://domain:10080/path
• https://domain:443/path
• https://domain:10443/path

The protocol doesn't necessary determines the port the service is running on.

[nils-ballmann]

This is merged in #60 an can be closed.