Good news: you probably do not need mod_rewrite.
Try this:
<VirtualHost 172.29.11.12:80>
ServerName www.in.abc.org
ProxyVia off
Redirect / http://www.in.abc.org/wps/portal
<Location /wps>
ProxyPass http://www.dev01.abc.org:9081/wps
ProxyPassReverse http://www.dev01.abc.org:9081/wps
</Location>
</VirtualHost>
Works for me, should work for you too. www.dev01.abc.org could be an alias for www.in.abc.org or vice-versa since from what I understand, they both share the same IP address.
As pointed out previously, your problem lies in the domain of the cookies served by WAS. My guess is that those cookies are in the dev01.abc.org domain, whereas the browsers access the application in the in.abc.org domain in which the cookies would not apply.
As all the users are located only in the in.abc.org domain, you can change the domain name of WAS through the WAS Administrative Console Security->Authentication Mechanisms->LTPA. Set the value of the "Domain Name" field to "in.abc.org". This would set the domain of the JSESSIONID cookie to a value which would allow the client browsers to include the cookie in the requests.
If you don't, the browser will not include the cookies in the requests.
Another way of doing this would be to use the ProxyPassReverseCookieDomain directive:
ProxyPassReverseCookieDomain .dev01.abc.org .in.abc.org
Unfortunately this directive has not been implemented in any release of Apache 2.0. You would need to apply patch 11915 (see Bugzilla bug report 10722).
In order to debug such problems, if you use MSIE I would strongly urge you to use a tool like HTTPWatch (http://www.httpwatch.com/default.htm) which will allow you to see the headers and cookies in requests as well as in responses, whether a page was served from cache, etc. It gives you a very nice insight into all requests and responses. I you use Mozilla, I understand there is a similar feature called something like "Live HTTP Headers".
Another way of investigating such problems might be using a network sniffer like Ethereal, or a proxy like Burp. That's would be my second choice though, because a browser plug-in is a lot more user-friendly.
For a little cookie tutorial, look at http://www.httpwatch.com/httpgallery/cookies/.
-ascs
-----Original Message-----
From: Ranjan, Rajiv [mailto:Rajiv.Ranjan@xxxxxxxxxxxx]
Sent: Thursday, July 21, 2005 8:20 AM
To: Axel-Stéphane SMORGRAV
Subject: RE: [users@httpd] Reverse proxing through apache where backend server uses cookie authentication
Hi Axel,
Thank you for replying. I am still struck with the issue.
As your mail suggests, you might already have done something similar to what I am trying to do. So, I will explain you the entire scenario in detail.
Maybe you would be able to help me.
I have an application running on WebSphere Portal server in domain "dev01.abc.org" and I have my proxy server in "in.abc.org".
As all the users who would be accessing the application are in "in.abc.org"
domain, my primary aim at getting a proxy is that it can do the url rewriting and the users wouldn't have to give the fully qualified name of the app server machine in the browser to access the application.
I also tried installing apache on my app server machine (i.e. on "dev01.abc.org" domain machine) and tried to see if its working but it doesn't work there either (I have attached the conf for this).
I am new to apache and url rewriting, can you please tell me if I am doing something wrong here or do I also need to do some changes in WebSphere console.
My rewriting configuration is as follows -
<VirtualHost 172.29.11.12:80>
ServerName 172.29.11.12
ProxyVia on
RewriteEngine on
RewriteLog logs/rajiv_rewrite.log
RewriteLogLevel 9
Redirect / http://172.29.11.12:80/wps/portal
RewriteRule ^/(.*)/myportal(.*) http://172.29.11.12:9081/wps/myportal%{REQUEST_URI}/http/172.29.11.12:80/wps/myportal$1 [P]
</VirtualHost>
_Rajiv
---------------------------------------------------------------------
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@xxxxxxxxxxxxxxxx
" from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|