Return-Path: Delivered-To: apmail-httpd-users-archive@www.apache.org Received: (qmail 72931 invoked from network); 29 Oct 2009 23:48:48 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 29 Oct 2009 23:48:48 -0000 Received: (qmail 88921 invoked by uid 500); 29 Oct 2009 23:48:45 -0000 Delivered-To: apmail-httpd-users-archive@httpd.apache.org Received: (qmail 88896 invoked by uid 500); 29 Oct 2009 23:48:44 -0000 Mailing-List: contact users-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: users@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@httpd.apache.org Received: (qmail 88887 invoked by uid 99); 29 Oct 2009 23:48:44 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 29 Oct 2009 23:48:44 +0000 X-ASF-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,WEIRD_PORT X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of aw@ice-sa.com designates 212.85.38.228 as permitted sender) Received: from [212.85.38.228] (HELO tor.combios.es) (212.85.38.228) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 29 Oct 2009 23:48:41 +0000 Received: from localhost (localhost [127.0.0.1]) by tor.combios.es (Postfix) with ESMTP id 87A6F2260A7 for ; Fri, 30 Oct 2009 00:48:19 +0100 (CET) Received: from tor.combios.es ([127.0.0.1]) by localhost (tor.combios.es [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DETg+i+vC7e6 for ; Fri, 30 Oct 2009 00:48:19 +0100 (CET) Received: from [192.168.245.129] (p549EAF91.dip0.t-ipconnect.de [84.158.175.145]) by tor.combios.es (Postfix) with ESMTPA id 998282260A6 for ; Fri, 30 Oct 2009 00:48:18 +0100 (CET) Message-ID: <4AEA29B7.1040700@ice-sa.com> Date: Fri, 30 Oct 2009 00:48:07 +0100 From: =?ISO-8859-1?Q?Andr=E9_Warnier?= Reply-To: users@httpd.apache.org User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: users@httpd.apache.org References: <6E76C122-80D1-410B-B333-6852250C8330@cornell.edu> <4AE85FF6.8040409@ice-sa.com> <0210B771-9D91-41F5-B5FF-859A74CA42D7@cornell.edu> <8AC8F496-98AF-48ED-9881-D12CFB0DCF2F@cornell.edu> In-Reply-To: <8AC8F496-98AF-48ED-9881-D12CFB0DCF2F@cornell.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [users@httpd] accessing REMOTE_USER through an Apache proxy Devin, I still have some lingering doubt about whether there is not a confusion somewhere between - the Apache process's environment values (what it gets in its own environment when it starts up) - the Apache "internal environment variables" (set internally by Apache, for Apache only, during one request), which when using the mod_jk connector to forward requests to Tomcat via AJP, become known as "request attributes" (a better name, in my opinion, less confusing) - HTTP request headers and their content - cgi-bin environment values (set by Apache in the environment of a child process just prior to running the cgi program in it). All these things above are distinct animals. Apache does for instance take the value of /some/ HTTP request headers, and translates them into /some/ environment values for cgi-bin programs, but the HTTP request headers and cgi-bin environment values are distinct items, and there is not a one-to-one relationship between them. They do not even necessarily have the same name. It took me a while to "click" on this, but I believe that what you are seeing with your cgi-bin script is : - your Apache setup sets a HTTP Header "REMOTE_USER", and proxies that modified request - the request is received by (another instance of) Apache, which calls a cgi-bin script to handle it. - prior to calling the cgi-bin script, Apache picks up the content of the HTTP header named "REMOTE_USER", and sets up that content as a *cgi-bin environment variable* named "HTTP_REMOTE_USER". - then in your cgi script, you are not looking at the HTTP header "REMOTE_USER" (which was received by Apache), but you are looking for an *environment variable* "REMOTE_USER", which is not there. It is not there because the cgi-bin environment variable (as set by Apache) is named "HTTP_REMOTE_USER". Get the difference ? A cgi-bin script does not, in general, have access to the HTTP headers that came in with the request which caused Apache to run this cgi-bin script. Instead, Apache "translates" *some* of these request HTTP headers into cgi-bin environment variables, to which the cgi-bin program *does* have access. (For example, Apache also splits off the query-string part of the request URL, and passes it to the cgi-bin program as the environment variable QUERY_STRING. But that was never a HTTP request header.) - But when you are going to pass this request to Glassfish, Apache is not going to set up environment values for Glassfish. It is going to pass HTTP headers. And one of them *will* be "REMOTE_USER:". So in fact you have already solved your problem. You are just testing it with the wrong tool. If your Apache server is set up with mod_perl, I could give you a Perl cgi-bin script which would show you the difference. That's because under mod_perl, Perl cgi-bin scripts *can* ask Apache for the original HTTP request headers. Devin Bougie wrote: > I have tried a different approach by moving the RewriteRules into the > Location directive. With this configuration, the HTTP_REMOTE_USER > variable is set and visible by the backend script and application. > However, REMOTE_USER is still blank. Here is the alternate configuration: > ------ > > order deny,allow > deny from all > AuthType KerberosV5 > AuthName "W4restrict" > KrbDefaultInstance net > Satisfy any > require valid-user > RewriteEngine on > RewriteCond %{REMOTE_USER} (.+) > RequestHeader Set Proxy-ip %{REMOTE_ADDR}e > RequestHeader Set Host ourserver.com:443 > RequestHeader set REMOTE_USER %{REMOTE_USER}e > RewriteRule ^/var/www/html/test/(.*) > http://localhost/cgi-bin/test/$1 [P,L,E=REMOTE_USER:%{REMOTE_USER}] > > ------ > And here is what we see in rewrite.log: > ------ > 192.168.213.159 - dab66 [29/Oct/2009:11:04:47 --0400] > [ourserver.com/sid#8885358][rid#971a7d0/initial] (3) [per-dir /test/] > add path info postfix: /var/www/html/test -> /var/www/html/test/remote.cgi > 192.168.213.159 - dab66 [29/Oct/2009:11:04:47 --0400] > [ourserver.com/sid#8885358][rid#971a7d0/initial] (3) [per-dir /test/] > applying pattern '^/var/www/html/test/(.*)' to uri > '/var/www/html/test/remote.cgi' > 192.168.213.159 - dab66 [29/Oct/2009:11:04:47 --0400] > [ourserver.com/sid#8885358][rid#971a7d0/initial] (4) RewriteCond: > input='dab66' pattern='(.+)' => matched > 192.168.213.159 - dab66 [29/Oct/2009:11:04:47 --0400] > [ourserver.com/sid#8885358][rid#971a7d0/initial] (2) [per-dir /test/] > rewrite /var/www/html/test/remote.cgi -> > http://localhost/cgi-bin/test/remote.cgi > 192.168.213.159 - dab66 [29/Oct/2009:11:04:47 --0400] > [ourserver.com/sid#8885358][rid#971a7d0/initial] (5) setting env > variable 'REMOTE_USER' to 'dab66' > 192.168.213.159 - dab66 [29/Oct/2009:11:04:47 --0400] > [ourserver.com/sid#8885358][rid#971a7d0/initial] (2) [per-dir /test/] > forcing proxy-throughput with http://localhost/cgi-bin/test/remote.cgi > 192.168.213.159 - dab66 [29/Oct/2009:11:04:47 --0400] > [ourserver.com/sid#8885358][rid#971a7d0/initial] (1) [per-dir /test/] > go-ahead with proxy request > proxy:http://localhost/cgi-bin/test/remote.cgi [OK] > ------ > > Any suggestions for passing REMOTE_USER through an Apache proxy would be > greatly appreciated. > > Many Thanks, > Devin > > On Oct 28, 2009, at 4:03 PM, Devin Bougie wrote: >> ... For what it's worth, I have tried inserting a RewriteCond to make >> sure the proxy only occurs when REMOTE_USER is set. This cleaned up >> the rewrite.log file a bit, but the script is still not able to see >> REMOTE_USER. Here is our updated configuration and rewrite.log. >> >> ------ >> ###### >> # GlassFish proxy >> ProxyPreserveHost on >> >> RewriteEngine on >> RewriteCond %{LA-U:REMOTE_USER} (.+) >> RewriteLog /var/log/httpd/rewrite.log >> RewriteLogLevel 9 >> >> RequestHeader Set Proxy-keysize 512 >> RequestHeader Set Proxy-ip %{REMOTE_ADDR}e >> RequestHeader Set Host ourserver.com:443 >> RequestHeader set REMOTE_USER %{LA-U:REMOTE_USER}e >> >> RewriteRule ^/test$ /test/ [R,L] >> RewriteRule ^/test/(.*) http://localhost/cgi-bin/test/$1 >> [P,L,E=REMOTE_USER:%{LA-U:REMOTE_USER}] >> >> order deny,allow >> deny from all >> AuthType KerberosV5 >> AuthName "kerberos authentication" >> Satisfy any >> require valid-user >> >> ------ >> ... [rid#8e23fc0/initial] (2) init rewrite engine with requested uri >> /test/remote.cgi >> ... [rid#8e23fc0/initial] (3) applying pattern '^/test$' to uri >> '/test/remote.cgi' >> ... [rid#8e23fc0/initial] (3) applying pattern '^/test/(.*)' to uri >> '/test/remote.cgi' >> ... [rid#8e23fc0/initial] (2) rewrite /test/remote.cgi -> >> http://localhost/cgi-bin/test/remote.cgi >> ... [rid#8e38648/subreq] (2) init rewrite engine with requested uri >> /test/remote.cgi >> ... [rid#8e38648/subreq] (1) pass through /test/remote.cgi >> ... [rid#8e23fc0/initial] (5) lookahead: path=/test/remote.cgi >> var=REMOTE_USER -> val=dab66 >> ... [rid#8e23fc0/initial] (5) setting env variable 'REMOTE_USER' to >> 'dab66' >> ... [rid#8e23fc0/initial] (2) forcing proxy-throughput with >> http://localhost/cgi-bin/test/remote.cgi >> ... [rid#8e23fc0/initial] (1) go-ahead with proxy request >> proxy:http://localhost/cgi-bin/test/remote.cgi [OK] >> ------ >> >> Our end goal is to proxy from the Apache server to a GlassFish >> Enterprise Server. Just for reference, here is the rewrite.log for a >> request that's proxied to a GlassFish Web Application. >> ------ >> ... [rid#8e23fc8/initial] (2) init rewrite engine with requested uri >> /HelloWeb/UserServlet >> ... [rid#8e23fc8/initial] (3) applying pattern '^/HelloWeb$' to uri >> '/HelloWeb/UserServlet' >> ... [rid#8e23fc8/initial] (3) applying pattern '^/HelloWeb/(.*)' to >> uri '/HelloWeb/UserServlet' >> ... [rid#8e23fc8/initial] (2) rewrite /HelloWeb/UserServlet -> >> http://localhost:38080/HelloWeb/UserServlet >> ... [rid#8e1ffb8/subreq] (2) init rewrite engine with requested uri >> /HelloWeb/UserServlet >> ... [rid#8e1ffb8/subreq] (1) pass through /HelloWeb/UserServlet >> ... [rid#8e23fc8/initial] (5) lookahead: path=/HelloWeb/UserServlet >> var=REMOTE_USER -> val=dab66 >> ... [rid#8e23fc8/initial] (5) setting env variable 'REMOTE_USER' to >> 'dab66' >> ... [rid#8e23fc8/initial] (2) forcing proxy-throughput with >> http://localhost:38080/HelloWeb/UserServlet >> ... [rid#8e23fc8/initial] (1) go-ahead with proxy request >> proxy:http://localhost:38080/HelloWeb/UserServlet [OK] >> ------ >> >> Any suggestions would be greatly appreciated. >> >> Thank you again, >> Devin >> >> On Oct 28, 2009, at 11:15 AM, Andr� Warnier wrote: >> >>> Devin Bougie wrote: >>> ... >>> >>> Hi. >>> >>> I'll give you my interpretation, after looking at the log, not really >>> at the configuration. >>> >>> I think the confusion may be about when and where, things happen >>> exactly. And it is not really helped by your choice to proxy from >>> your server to itself.. >>> >>> If you examine the log below, you will see different/distinct >>> requests, identified by their respective "rid" number. >>> >>> The first is the request rid#8aa28f8 that comes in originally, on >>> your "first" server (before the proxying occurs). >>> That one does the proxying before your is even >>> invoked (in my opinion). So at that point, the authentication has >>> not even happened, and REMOTE_USER is undefined or empty. >>> That request, you then proxy to your "second" server. >>> >>> Now the proxied request comes in to your "second" server. That is >>> request rid#8aa8908. That one starts without a REMOTE_USER (see >>> above), but then goes through the section, where it >>> acquires an id. >>> But by then it is too late for proxying.. >>> >>> It would all probably be clearer if you set this up in two distinct >>> VirtualHosts, and proxied from the first to the second. >>> >>> Another thing, is that Apache "environment variables", are kind of >>> "virtual", in the sense that they exist inside of Apache, for the >>> duration of one request. >>> When you proxy something to another server, this is a new request, >>> and this other server does not magically inherit the environment of >>> your first request in the first server. >>> To pass it on, you would have to set it in a header which you pass to >>> the second server. But then, you must have a value to pass, by the >>> time you create the header. >>> Which does not seem to be the case here. >>> >>> Hope that is clear. >>> As for me, I think I need a cup of coffee now. >>> >>> >>>> ------ >>>> ###### >>>> # GlassFish proxy >>>> ProxyPreserveHost on >>>> RewriteEngine on >>>> RewriteLog /var/log/httpd/rewrite.log >>>> RewriteLogLevel 9 >>>> RequestHeader Set Proxy-keysize 512 >>>> RequestHeader Set Proxy-ip %{REMOTE_ADDR}e >>>> RequestHeader Set Host ourserver.com:443 >>>> RequestHeader set REMOTE_USER %{LA-U:REMOTE_USER}e >>>> RewriteRule ^/test$ /test/ [R,L] >>>> RewriteRule ^/test/(.*) http://localhost/cgi-bin/test/$1 >>>> [P,L,E=REMOTE_USER:%{LA-U:REMOTE_USER}] >>>> >>>> order deny,allow >>>> deny from all >>>> AuthType KerberosV5 >>>> AuthName "kerberos authentication" >>>> Satisfy any >>>> require valid-user >>>> >>>> ------ >>>> And here is what I see in rewrite.log. REMOTE_USER is eventually >>>> set properly, just not soon enough for the script. >>>> ------ >>>> ... [rid#8aa28f8/initial] (2) init rewrite engine with requested uri >>>> /test/remote.cgi >>>> ... [rid#8aa28f8/initial] (3) applying pattern '^/test$' to uri >>>> '/test/remote.cgi' >>>> ... [rid#8aa28f8/initial] (3) applying pattern '^/test/(.*)' to uri >>>> '/test/remote.cgi' >>>> ... [rid#8aa28f8/initial] (2) rewrite /test/remote.cgi -> >>>> http://localhost/cgi-bin/test/remote.cgi >>>> ... [rid#8aa4900/subreq] (2) init rewrite engine with requested uri >>>> /test/remote.cgi >>>> ... [rid#8aa4900/subreq] (1) pass through /test/remote.cgi >>>> ... [rid#8aa28f8/initial] (5) lookahead: path=/test/remote.cgi >>>> var=REMOTE_USER -> val= >>>> ... [rid#8aa28f8/initial] (5) setting env variable 'REMOTE_USER' to '' >>>> ... [rid#8aa28f8/initial] (2) forcing proxy-throughput with >>>> http://localhost/cgi-bin/test/remote.cgi >>>> ... [rid#8aa28f8/initial] (1) go-ahead with proxy request >>>> proxy:http://localhost/cgi-bin/test/remote.cgi [OK] >>>> ... [rid#8aa8908/initial] (2) init rewrite engine with requested uri >>>> /test/remote.cgi >>>> ... [rid#8aa8908/initial] (3) applying pattern '^/test$' to uri >>>> '/test/remote.cgi' >>>> ... [rid#8aa8908/initial] (3) applying pattern '^/test/(.*)' to uri >>>> '/test/remote.cgi' >>>> ... [rid#8aa8908/initial] (2) rewrite /test/remote.cgi -> >>>> http://localhost/cgi-bin/test/remote.cgi >>>> ... [rid#8abcf90/subreq] (2) init rewrite engine with requested uri >>>> /test/remote.cgi >>>> ... [rid#8abcf90/subreq] (1) pass through /test/remote.cgi >>>> ... [rid#8aa8908/initial] (5) lookahead: path=/test/remote.cgi >>>> var=REMOTE_USER -> val=dab66 >>>> ... [rid#8aa8908/initial] (5) setting env variable 'REMOTE_USER' to >>>> 'dab66' >>>> ... [rid#8aa8908/initial] (2) forcing proxy-throughput with >>>> http://localhost/cgi-bin/test/remote.cgi >>>> ... [rid#8aa8908/initial] (1) go-ahead with proxy request >>>> proxy:http://localhost/cgi-bin/test/remote.cgi [OK] >>>> ------ >>>> Any suggestions would be greatly appreciated. Please let me know if >>>> there is any more information I can provide. >>>> Many thanks, >>>> Devin >>> >>> >>> --------------------------------------------------------------------- >>> The official User-To-User support forum of the Apache HTTP Server >>> Project. >>> See for more info. >>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org >>> " from the digest: users-digest-unsubscribe@httpd.apache.org >>> For additional commands, e-mail: users-help@httpd.apache.org >>> >> > > --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See for more info. To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org " from the digest: users-digest-unsubscribe@httpd.apache.org For additional commands, e-mail: users-help@httpd.apache.org