You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by Devin Bougie <De...@cornell.edu> on 2009/10/28 15:45:10 UTC
[users@httpd] accessing REMOTE_USER through an Apache proxy
We proxy connections trough Apache to GlassFish Web Applications, and
would like to give those applications access to the http REMOTE_USER
variable. To make sure this is not related to GlassFish, I have
created a very basic test script. The kerberos authentication and
Apache proxy work properly, and the script is able to see the
REMOTE_USER variable when called directly. However, the script can
not see the REMOTE_USER variable when it's accessed through a proxy.
It seems as though this has been discussed several times, but I have
not been able to make any of the proposed solutions work.
Here is the relevant portion of our configuration file file.
------
######
# 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}]
<Location "/test">
order deny,allow
deny from all
AuthType KerberosV5
AuthName "kerberos authentication"
Satisfy any
require valid-user
</Location>
------
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
Re: [users@httpd] accessing REMOTE_USER through an Apache proxy
Posted by Devin Bougie <De...@cornell.edu>.
On Oct 30, 2009, at 12:49 PM, André Warnier wrote:
> Glad to have been of help.
> One more nitpick however, below, lest you remain partly confused.
Yes, indeed. I was confused by the "Same as the value of the CGI
variable REMOTE_USER." statement in the
HttpServletRequest.getRemoteUser javadoc, but you have again helped
explain that.
Thanks again,
Devin
>
> Devin Bougie wrote:
> ...
>
> With the latest posted configuration,
>> I am able to see the REMOTE_USER HTTP header from the backend
>> GlassFish Web Application (using HttpServletRequest.getHeader
>> ("REMOTE_USER")).
> OK, and correct.
>
> As
>> you explain, HttpServletRequest.getRemoteUser and getUserPrincipal
>> both return null because they are looking for the REMOTE_USER cgi-
>> bin environment variable.
> No, they are not.
> A cgi-bin environment variable is only set by a webserver when
> running a cgi-bin program.
> A servlet is not a cgi-bin program, and the servlet container which
> runs it, does not set any "environment variables" for the servlet.
> If HttpServletRequest.getRemoteUser and
> HttpServletRequest.getUserPrincipal return null, it is because they
> both look into the UserPrincipal object, which is probably not set,
> because you have not done any authentication (yet) in your servlet
> container.
>
> You have just read a HTTP header, and gotten back a String as a
> result. That does not, for the servlet container, constitute reason
> enough to take that String, consider it as a bona fide user-id, and
> set it into the UserPrincipal object so that
> HttpServletRequest.getRemoteUser would nicely return it. Hence the
> nulls.
>
> So it looks like you still have some work to do.
> But that is now a question which belongs to the GlassFish forum.
>
>
> ---------------------------------------------------------------------
> The official User-To-User support forum of the Apache HTTP Server
> Project.
> See <URL:http://httpd.apache.org/userslist.html> 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
>
Re: [users@httpd] accessing REMOTE_USER through an Apache proxy
Posted by André Warnier <aw...@ice-sa.com>.
Hi.
Glad to have been of help.
One more nitpick however, below, lest you remain partly confused.
Devin Bougie wrote:
...
With the latest posted configuration,
> I am able to see the REMOTE_USER HTTP header from the backend GlassFish
> Web Application (using HttpServletRequest.getHeader("REMOTE_USER")).
OK, and correct.
As
> you explain, HttpServletRequest.getRemoteUser and getUserPrincipal both
> return null because they are looking for the REMOTE_USER cgi-bin
> environment variable.
No, they are not.
A cgi-bin environment variable is only set by a webserver when running a
cgi-bin program.
A servlet is not a cgi-bin program, and the servlet container which runs
it, does not set any "environment variables" for the servlet.
If HttpServletRequest.getRemoteUser and
HttpServletRequest.getUserPrincipal return null, it is because they both
look into the UserPrincipal object, which is probably not set, because
you have not done any authentication (yet) in your servlet container.
You have just read a HTTP header, and gotten back a String as a result.
That does not, for the servlet container, constitute reason enough to
take that String, consider it as a bona fide user-id, and set it into
the UserPrincipal object so that HttpServletRequest.getRemoteUser would
nicely return it. Hence the nulls.
So it looks like you still have some work to do.
But that is now a question which belongs to the GlassFish forum.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> 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
Re: [users@httpd] accessing REMOTE_USER through an Apache proxy
Posted by Devin Bougie <De...@cornell.edu>.
Hi André,
Thank you very much for another thorough explanation. This certainly
does help clear up my confusion. With the latest posted
configuration, I am able to see the REMOTE_USER HTTP header from the
backend GlassFish Web Application (using HttpServletRequest.getHeader
("REMOTE_USER")). As you explain, HttpServletRequest.getRemoteUser
and getUserPrincipal both return null because they are looking for the
REMOTE_USER cgi-bin environment variable.
For what it's worth, here is an excerpt from the CGI script I was
testing with. When calling the script directly, $REMOTE_USER is set
but $HTTP_REMOTE_USER is not. When accessing the script through the
proxy (using the latest posted configuration), $HTTP_REMOTE_USER is
set but $REMOTE_USER is not.
------
# test for $REMOTE_USER
if [ -z "$REMOTE_USER" ]; then
echo '$REMOTE_USER not set.'
else echo "REMOTE_USER is $REMOTE_USER"
fi
# test for $HTTP_REMOTE_USER
if [ -z "$HTTP_REMOTE_USER" ]; then
echo '$HTTP_REMOTE_USER not set.'
else echo "HTTP_REMOTE_USER is $HTTP_REMOTE_USER"
fi
echo ''
echo 'Environment is:'
printenv
------
I believe being able to access the REMOTE_USER HTTP header achieves
our goal. Thank you very much for all of your time and help.
Sincerely,
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:
>> ------
>> <Location "/test">
>> 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}]
>> </Location>
>> ------
>> 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}]
>>> <Location "/test">
>>> order deny,allow
>>> deny from all
>>> AuthType KerberosV5
>>> AuthName "kerberos authentication"
>>> Satisfy any
>>> require valid-user
>>> </Location>
>>> ------
>>> ... [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 <Location /test> 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 <Location> 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}]
>>>>> <Location "/test">
>>>>> order deny,allow
>>>>> deny from all
>>>>> AuthType KerberosV5
>>>>> AuthName "kerberos authentication"
>>>>> Satisfy any
>>>>> require valid-user
>>>>> </Location>
>>>>> ------
>>>>> 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 <URL:http://httpd.apache.org/userslist.html> 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 <URL:http://httpd.apache.org/userslist.html> 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 <URL:http://httpd.apache.org/userslist.html> 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
Re: [users@httpd] accessing REMOTE_USER through an Apache proxy
Posted by André Warnier <aw...@ice-sa.com>.
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:
> ------
> <Location "/test">
> 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}]
> </Location>
> ------
> 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}]
>> <Location "/test">
>> order deny,allow
>> deny from all
>> AuthType KerberosV5
>> AuthName "kerberos authentication"
>> Satisfy any
>> require valid-user
>> </Location>
>> ------
>> ... [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 <Location /test> 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 <Location> 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}]
>>>> <Location "/test">
>>>> order deny,allow
>>>> deny from all
>>>> AuthType KerberosV5
>>>> AuthName "kerberos authentication"
>>>> Satisfy any
>>>> require valid-user
>>>> </Location>
>>>> ------
>>>> 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 <URL:http://httpd.apache.org/userslist.html> 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 <URL:http://httpd.apache.org/userslist.html> 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
Re: [users@httpd] accessing REMOTE_USER through an Apache proxy
Posted by Devin Bougie <De...@cornell.edu>.
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:
------
<Location "/test">
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}]
</Location>
------
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}]
> <Location "/test">
> order deny,allow
> deny from all
> AuthType KerberosV5
> AuthName "kerberos authentication"
> Satisfy any
> require valid-user
> </Location>
> ------
> ... [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 <Location /test> 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 <Location> 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}]
>>> <Location "/test">
>>> order deny,allow
>>> deny from all
>>> AuthType KerberosV5
>>> AuthName "kerberos authentication"
>>> Satisfy any
>>> require valid-user
>>> </Location>
>>> ------
>>> 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 <URL:http://httpd.apache.org/userslist.html> 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
>>
>
Re: [users@httpd] accessing REMOTE_USER through an Apache proxy
Posted by Devin Bougie <De...@cornell.edu>.
Hi André,
Thank you very much for your time and explanation. 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}]
<Location "/test">
order deny,allow
deny from all
AuthType KerberosV5
AuthName "kerberos authentication"
Satisfy any
require valid-user
</Location>
------
... [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 <Location /test> 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 <Location> 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}]
>> <Location "/test">
>> order deny,allow
>> deny from all
>> AuthType KerberosV5
>> AuthName "kerberos authentication"
>> Satisfy any
>> require valid-user
>> </Location>
>> ------
>> 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 <URL:http://httpd.apache.org/userslist.html> 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
>
Re: [users@httpd] accessing REMOTE_USER through an Apache proxy
Posted by André Warnier <aw...@ice-sa.com>.
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 <Location /test> 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 <Location> 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}]
> <Location "/test">
> order deny,allow
> deny from all
> AuthType KerberosV5
> AuthName "kerberos authentication"
> Satisfy any
> require valid-user
> </Location>
> ------
>
> 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 <URL:http://httpd.apache.org/userslist.html> 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