cookie-based sessions with mod_rewrite
cookie-based sessions with mod_rewrite
- Subject: cookie-based sessions with mod_rewrite
- From: Zak Burke <email@hidden>
- Date: Fri, 03 Dec 2004 16:12:41 -0500
I just spent a day trying to figure out why cookie-based
authentication to a mod_rewrite-based WO app was failing from
Safari. We figured out the problem was related to the wosid cookie's
path and found the oh-so-simple solution thanks to posts from Gary
Teter and Chuck Hill.
Here is the solution, for the impatient:
in Session.java, override domainForIDCookies to have the WO-related
cookies sent with all requests to your site:
public String domainForIDCookies()
{
return "/";
}
The source of the hangup (details below) is clearly explained in
Apple's API documentation for WOSession:
http://developer.apple.com/documentation/WebObjects/Reference/API/com/webobjects/appserver/WOSession.html
but you still have to know to look there rather than in, say, the
documentation for WOApplication or WOCookie, which is where I got
lost for a while.
Here is the problem, for the curious:
If you use mod_rewrite to map requests from, say, /login.html to
/cgi-bin/WebObjects/myapp.woa/wa/login, the browser won't send the
wosid and woinst cookies because /cgi-bin/WebObjects/myapp.woa (the
cookie path) isn't a sub-string of /login.html (the request path).
Some details about cookies are in order to make sense of this. When
a browser makes a request to a server for a page, it only sends
cookies that match the domain and path. For example, cookies with
the domain apple.com aren't sent to anothersite.com, and cookies
with the path /web-apps/WebObjects/myapp.woa aren't sent to
/cgi-bin/script.cgi. Both the cookie's domain and path have to be
subsets of the request's domain and path for it to be sent.
This means a cookie with a domain of .mysite.edu will be sent to
www.mysite.edu and foo.mysite.edu but not www.somesite.com, etc.
Likewise, a cookie with a path of /some will be sent with requests
like /some/file.html and /some/other/file.html but not
/plain/file.html.
To fix the problem, you have to set the cookie path in a way that
will cause the browser to send it with its pre-rewrite requests.
Overriding WOSession.domainForIDCookies to return / instead of the
default (something like /cgi-bin/WebObjects/appname.woa) does this.
As above, this is clearly explained in the documentation for
WOSession, but you have to know the method is on WOSession and that
it's misnamed (WOApplication.pathForIDCookies would have been my
choice).
I hope this saves somebody a few grey hairs; I'm already a lost cause.
zak.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden