Re: [cgiapp] User authentication

[Drew Taylor <suppressed>]

On Sun, 31 Oct 2004 20:35:27 +1100, Cees Hek <suppressed> wrote:
> On Fri, 29 Oct 2004 11:16:30 -0400, Drew Taylor
> 
> 
> <suppressed> wrote:
> > On Fri, 29 Oct 2004 16:31:40 +1000, Cees Hek <suppressed> wrote:

> Could you elaborate on using Roles?  It may be that we are thinking of
> the same thing, but using different terminologies.
> 
> Generally what I do is setup a group for every type of task that needs
> to be done.  Some examples of group names would be editusers,
> editcontent, publishcontent.

Ahhh, I think we are talking about nearly the same thing then. You
define (many) different, small groups (ie. permissions) and say User A
is in groups 1,2, & 3,  but User B is only in 2 & 3. My idea of roles
is similar in that you have a bunch of granular permissions, but you
can define a Role to wrap up a bunch of these individual permissions.
So rather than saying User A is in groups 1,2,3, I can say User A has
the PowerUser role, and User B has the User role. This has the
advantage of giving the user a single Role rather than having to set
many different individual permissions for each user.

> > I have to go with Owain and disagree with you on this one. His example
> > was a perfect one: a user can edit their own profile (or list of
> > classes, etc), but they definitely can't modify someone else's, or
> > maybe even view it. Also, if you are doing role based authentication
> > you'll need the ability to disallow access to some functionality but
> > allow others.
> 
> I don't see how that applies.  In that situation I would have a User
> module which has a runmode where any user can edit their own profile.
> And I would have a UserEditor module which has runmodes to list and
> edit any user.  This separates administration tasks and end user tasks
> making it much easier to manage security.

I see. That makes a lot of sense. I've done things like that in the
past, but I my thinking on this idea in my previous posts got a bit
too generic. :-)

> If your concern is that this method creates duplication (there is a
> runmode to change the user profile in both modules), I think that
> duplication is very minimal.  90% of the work for chaning a user
> profile is done in my Data modules.  All the runmode has to do is load
> a user object and pass in the new values from the query object.

Good point. CDBI makes this very easy for me do to, and I assume
you're also using the same sort of framework.

> Regardless of how I implement authentication, I would not be against
> putting in support to handle runmode level authorization.  It would
> actually be quite straight forward.
> 
> $self->require_authorization(
>             runmode1 => ['group1', 'group2'],
>             runmode2 => 'group1,
> );
> 
> This would still be put in the 'setup' method so this only needs to be
> done once for each App module.

I like this approach. It's simple and straightforward to implement.
Anything else on top of this makes sense to do as a custom module.

> > > The only way that I can think to do it is to have the plugin add some
> > > new runmodes to the module!  Does anyone have any suggestions on how
> > > to do that cleanly?  Is it even wise?
> >
> > I think the right thing to do here is to have default login,
> > forbidden, and logout runmodes that the Auth plugin adds to the app
> > (maybe prefix the runmode names with "auth_" so we worry less about
> > clashing with other runmode names). Then an application can override
> > these methods to present a custom screen.
> 
> I don't know if that would work safely.  Loading the plugin would
> clobber any auth_login method that may have been created in the module
> by the user.  Remember the plugins don't work through inheritance but
> through exporting.

Oh, shoot. That does make it trickier. I suppose rather than blindly
using @EXPORT we could do "fun" things via import() to check for
existing subs before we stuff the default ones in via the symbol
table. Definitely less appealing than doing it through inheritance.

> Ideally we should be able to add to the list of runmodes that have
> been defined.  Then the user can either use the default runmode that
> is created, or they can provide the name of a runmode that should be
> used instead.

We can add runmodes at any time via run_modes(). I do this in my C::A
base class cgiapp_init() to add my login and no access runmodes. 
Perhaps the Auth module can export the default subs as
"default_auth_foo" and then the prerun hook we are adding can first
call "auth_foo" if it is defined, and "default_auth_foo" is not. Still
kind of ugly, but workable since this logic is completely outside the
real application code.

Drew
-- 
----------------------------------------------------------------
 Drew Taylor                 *  Web development & consulting
 Email: suppressed  *  Site implementation & hosting
 Web  : www.drewtaylor.com   *  perl/mod_perl/DBI/mysql/postgres
 ----------------------------------------------------------------

---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
              http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed