1. I believe you can write the cookie in a class that is chained as a filter in the filter to bean proxy. There are plenty of other options. The main concern is the order of operations. 2. Depends on your app requirements. If it is a simple auth token, you may not need db access. But remember if you are not using https, your data in the cookie is at risk.
Another option I would suggest is to use CAS. It would handle validating the authentication each time the user hits a new server. You would do the authorization piece only when necessary. This is definitely a more complex set up (with its own concerns) but for me it is preferable. You could also look at partial http session clustering but we all know how that usually goes... > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Vijay Varadan > Sent: Tuesday, December 06, 2005 11:13 PM > To: [email protected] > Subject: [Acegisecurity-developer] How can Acegi be used in a webfarm > without HttpSession? > > Acegi newbie here. :-) > > I did a search in the mailing list archives to see if there are any > posts on how to use Acegi in a webfarm, but I couldn't find any. In > case I'm not clear, I have a single web application that I'd like to > deploy on multiple web servers behind a load balancer and allow the > users to be able to bounce between the servers for various requests > within a "session" - of course, since a user can hit any of the > multiple web servers behind the load balancer, the session I'm > referring to is not an HttpSession object, but to the general meaning > of the term session as applied to a user's interaction with a web > site. > > From what I've seen of the Acegi source code and samples, the context > information seems to either be tied to the HttpSession (optionally > stored in EhCache) - in my situation, I would like to specify some > information in an encrypted cookie that contains among other things > the session start time, login-status, username if applicable and > retrieve the relevant data without using any cache (such as EhCache) > from the DB for each request. (Note that we do this is a conscious > trade-off we're making to enable a better user experience in case a > web server goes down and also to allow operations to be able to take > servers in and out of rotation as needed.) > > What exactly do I need to do to: > 1. write the cookie w/ the encrypted information? i.e. where do I do > this? > 2. read the cookie to get the relevant information to retrieve the > user record from the DB and stuff it into the threadlocal context? > i.e. where do I do this? > > Do I need to write my own replacement for > HttpSessionContextIntegrationFilter? i.e. one that will do the work of > looking for the appropriate cookie, retrieve the authetication object > and stuff it into the thread local security context? > > > Thanks > Vijay > NHu > > ~z^zzjɺ{ > > ,H4i
