On Thu, Mar 4, 2010 at 5:56 PM, Michael Peters <[email protected]>wrote:
> On 03/04/2010 10:56 AM, Brad Van Sickle wrote: > > > The way I handle that today is: > > 1) Authentication is pretty simple, I have a "Security" application that > > provides the login form, processes the login, hands out the session and > > then redirects the user to the actual app. > > Simple and pretty standard. Another way is to separate out the session > from the auth cookie. Session holds various things about what the user > has done, etc. The auth cookie holds things like user id and > groups/roles. You can make this auth cookie tamper proof by using a > hash, etc. Then you don't have to hit your database every time you want > to find out who the user is or what groups he's a part of. > > This is how mod_auth_tkt works and it's really nice because then you can > use the same auth scheme in your proxies as you do in your backend. > Hi Michael, With this approach, how to you handle user authorization changes, say by an administrator? In other words, how to you handle invalidating the auth cookie? Wouldn't a database lookup be required to ensure the auth cookie's info is still valid/current? (I started down this road, but when I implemented my admin pages and started testing, I found that newly unauthorized users still had access because of the (old) auth cookie data. I couldn't figure out a way around this, without hitting the database to check the auth cookie, at which point I didn't see the value of the auth cookie anymore.) -- Mark R. ##### CGI::Application community mailing list ################ ## ## ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## ## ## ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ## ## ################################################################
