[cgiapp] Security, Authentication and Authorization for CGI::App
Mark Rajcok
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.
>
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.
More information about the cgiapp
mailing list