2

I'm using Ubuntu 14.04 and have multiple Apache HTTP VirtualHosts listening on port 80. One site is reverse proxying for application listening on localhost. Apache has Basic authentification configured for root location on that site.

Here is apache config:

<VirtualHost *:80>
        DocumentRoot /home/korisnik/site
        Alias /static /home/korisnik/site/static
        <Directory /home/korisnik/site/static>
          Require all granted
        </Directory>

        ProxyPass /static !
        ProxyPass / http://127.0.0.1:9002/
        ProxyPassReverse / http://127.0.0.1:9002/

        RequestHeader set X-Proxy-USER %{REMOTE_USER}e  #
        RequestHeader set X-Proxy-SECURE-USER %{REMOTE_USER}s
        RequestHeader set X-Foo "Bar"

        <Location />
          AuthType Basic
          AuthName "Authentication Required"
          AuthUserFile "/home/korisnik/htpasswd"
          Require valid-user
        </Location>
</VirtualHost>

My goal is to pass authenticated user's username to backend application via ENV variable, and this worked on one server that had SSL module enabled in Apache, while on another server same configuration gave HTTP_X_PROXY_REMOTE_USER ENV variable set to null. Only difference between servers was enabled SSL module.

Documentation (http://httpd.apache.org/docs/current/mod/mod_headers.html) says that

RequestHeader set X-VARNAME %{VARNAME}e

should be used on nonSSL, while this on sites running SSL

RequestHeader set X-VARNAME %{VARNAME}s

Here is php script I use for dumping headers:

<?php
        print "REMOTE_USER: ".$_SERVER['REMOTE_USER']."\n";
        print "HTTP_X_PROXY_USER: ".$_SERVER['HTTP_X_PROXY_USER']."\n";
        print "HTTP_X_PROXY_SECURE_USER: ".$_SERVER['HTTP_X_PROXY_SECURE_USER']."\n";
        print "HTTP_X_FOO: ".$_SERVER['HTTP_X_FOO']."\n";
?>

I have found that while SSL is disabled, neither of these directives work. When SSL is enabled second directive work without any other change, like enabling SSL on that site, or enabling SSL on any other site for that matter.

Headers with Apache2 mod_ssl enabled and request going through ProxyPass

REMOTE_USER: 
HTTP_X_PROXY_USER: (null)
HTTP_X_PROXY_SECURE_USER: korisnik
HTTP_X_FOO: Bar

Headers with Apache2 mod_ssl enabled and request going direct to php file, without ProxyPass

REMOTE_USER: korisnik
HTTP_X_PROXY_USER: (null)
HTTP_X_PROXY_SECURE_USER: korisnik
HTTP_X_FOO: Bar

Headers with Apache2 mod_ssl disabled and request going through ProxyPass

REMOTE_USER: 
HTTP_X_PROXY_USER: (null)
HTTP_X_PROXY_SECURE_USER: (null)
HTTP_X_FOO: Bar

Headers with Apache2 mod_ssl disabled and request going direct to php file, without ProxyPass

REMOTE_USER: korisnik
HTTP_X_PROXY_USER: (null)
HTTP_X_PROXY_SECURE_USER: (null)
HTTP_X_FOO: Bar

Am I missing something, or Apache is refusing to set REMOTE_USER RequestHeader for connections behind Proxy directive while SSL module is disabled?

2

The problem seems to be that the remote user is not available via "%{REMOTE_USER}e" during the phase of the URL processing that the Header directive is evaluated. According to the RewriteRule documentation:

For instance, to rewrite according to the REMOTE_USER variable from within the per-server context (httpd.conf file) you must use %{LA-U:REMOTE_USER} - this variable is set by the authorization phases, which come after the URL translation phase (during which mod_rewrite operates).

I presume that it fails with the header directive for similar reasons. I do not know why it suddenly becomes available under SSL via "%{REMOTE_USER}s", but again I presume that it is because the remote user is set during an earlier phase when the communication is over SSL.

However, I do have a solution for your problem. You can use a RewriteRule to do the look ahead as per the documentation to get the remote user and then set a header accordingly.

RewriteEngine On
RewriteRule ^ - [E=MY_REMOTE_USER:%{LA-U:REMOTE_USER}]
RequestHeader set X-Proxy-USER %{MY_REMOTE_USER}e

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.