[cgiapp] Security, Authentication and Authorization for CGI::App
mrajcok at gmail.com
Fri Mar 5 12:11:26 EST 2010
On Thu, Mar 4, 2010 at 5:56 PM, Michael Peters <mpeters at plusthree.com>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.
With this approach, how to you handle user authorization changes, say by an
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
(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.
More information about the cgiapp