Problem with mod rewrite with proxypass

Problems adding parameters using rewrite in combination with mod_proxy

[kewlhand]

I currently front end an ajax app and a tomcat based xsql/xml publishing system with apache, and I have been doing that successfully using:

 ProxyPass /xs http://127.0.0.1:8080/st
 ProxyPassReverse /xs http://127.0.0.1:8080/st

However, now I wish to ensure that I always add the REMOTE_USER apache session variable to the xsql URL using mod_rewrite. I used the following:

  RewriteCond %{LA-U:REMOTE_USER} (.*)$
  RewriteRule ^(.*)\.xsql $1.xsql?p_username=%1 [QSA,L]

However, when I do this, although the rewrite is successfull (according to rewrite logs), it then fails to pass the rewritten URL to the proxy module.
If I add the 'P' flag:

  RewriteCond %{LA-U:REMOTE_USER} (.*)$
  RewriteRule ^(.*)\.xsql $1.xsql?p_username=%1 [QSA,L,P]

It goes recursive on adding parameters, and never makes it out the other end, ie the request never reaches tomcat, and the rewrite log shows the recursion.

Whats the correct way of doing this guys?

[jdMorgan]

Stop the loop:

RewriteCond %{QUERY_STRING} !^([^&]*&)*p_username=
RewriteCond %{LA-U:REMOTE_USER} ^(.*)$
RewriteRule ^(.*)\.xsql$ /$1.xsql?p_username=%1 [QSA,P]

Adding the leading slash in the RewriteRule substitution is a good idea, as it prevents the client from controlling the initial URL-path-part -- a potential exploit.

If this helps, test again without "LA-U:". It's best to avoid that if possible, because it can be really slow.

Jim

[kewlhand]

thanks, that stopped the iteration problem, but for reasons I cant fathom, I now DONT seem to be picking up the REMOTE_USER, here is the rewrite log on an initial url of http://machine.example.com/xs/AllOrganisations.xsql :


(2) init rewrite engine with requested uri /xs/AllOrganisations.xsql
(3) applying pattern '^(.*)\.xsql$' to uri '/xs/AllOrganisations.xsql'
(4) RewriteCond: input='' pattern='!^([^&]*&)*p_username=' => matched
2) init rewrite engine with requested uri /xs/AllOrganisations.xsql
3) applying pattern '^(.*)\.xsql$' to uri '/xs/AllOrganisations.xsql'
4) RewriteCond: input='' pattern='!^([^&]*&)*p_username=' => matched
4) RewriteCond: input='' pattern='^(.*)$' => matched
2) rewrite '/xs/AllOrganisations.xsql' -> '//xs/AllOrganisations.xsql?p_username='
3) split uri=//xs/AllOrganisations.xsql?p_username= -> uri=//xs/AllOrganisations.xsql, args=p_username=
2) forcing proxy-throughput with http://machine.example.com//xs/AllOrganisations.xsql
1) go-ahead with proxy request proxy:http://machine.example.com//xs/AllOrganisations.xsql [OK]
(5) lookahead: path=/xs/AllOrganisations.xsql var=REMOTE_USER -> val=
(4) RewriteCond: input='' pattern='^(.*)$' => matched
(2) rewrite '/xs/AllOrganisations.xsql' -> '//xs/AllOrganisations.xsql?p_username='
(3) split uri=//xs/AllOrganisations.xsql?p_username= -> uri=//xs/AllOrganisations.xsql, args=p_username=
(2) forcing proxy-throughput with http://machine.example.com//xs/AllOrganisations.xsql
(1) go-ahead with proxy request proxy:http://machine.example.com//xs/AllOrganisations.xsql [OK]
(2) init rewrite engine with requested uri /xs/AllOrganisations.xsql
(3) applying pattern '^(.*)\.xsql$' to uri '/xs/AllOrganisations.xsql'
(4) RewriteCond: input='p_username=' pattern='!^([^&]*&)*p_username=' => not-matched
(1) pass through /xs/AllOrganisations.xsql

[edited by: jdMorgan at 4:08 pm (utc) on Mar 1, 2010]
[edit reason] Change to example.com, disable smilies in code. [/edit]

[jdMorgan]

Look at your raw access logs for this request. Is the remote_user being logged for all appropriate requests?

If the Remote_user isn't present in all cases when required (for all URL-requests required) then you may need to grab it initially when avaiable, and save it in a client-side session cookie. Then modify your logic to check for remote_user and if not present then check the cookie %{HTTP_COOKIE}. If neither are present, request login. If remote_user is present, create the cookie, and if remote user is not present and the cookie is set, then accept the cookie value. This cookie testing must also be applied to the loop prevention.

Jim

[kewlhand]

ok, now you have me really confused, if the whole site is protected with basic authentication, why would REMOTE_USER be lost? isnt it fundamental to basic authentication? (if indeed it is lost, because all we have proven so far is it's not coming out with the current rewrite rule).

[kewlhand]

FYI, i've confirmed using a cgi script that REMOTE_USER is being set correctly for all requests, so clearly there must be a problem with the rewrite rules.

Many thanks for your help so far though, most appreciated...

[jdMorgan]

When thinking through these problems, it's important to ask both "What does this code do?" and "When does it do that?"

If this code runs before the server loads the REMOTE_USER variable from the HTTP Authentication request header, then that variable won't yet be defined. Although I suggested avoiding the "LA-U" look-ahead above, it may be required to assure that the HTTP header value is available as a server variable.

Jim

[kewlhand]

That doesnt really move me forward, i'm using the lookahead already (as you know), and authentication has definately been done by the time this url is called, which i've checked using a cgi to look at the session envs.

I did note another post on here with very similar problem, the user got around it by using %{LA-U:REMOTE_USER} instead of %1 on the right hand side of the rewrite rule. Unfortunately that had no effect for me.

Can the fact thats it's a VirtualHost be a factor in this?

This seemingly trivial problem has wasted soo much of my time, it's untrue.