Re: [cgiapp] User authentication

[Cees Hek <suppressed>]

On Mon, 1 Nov 2004 11:19:31 -0500, Drew Taylor
<suppressed> wrote:
> On Sun, 31 Oct 2004 20:35:27 +1100, Cees Hek <suppressed> wrote:
> > 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.

Sure, I've used that method as well.  It really depends on the app to
decide which strategy will work best.

> > 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. :-)

Well, there is no single 'right way to do it'.  I am just developing
along the lines of how I implement authorization, and trying to make
things generic enough so that other methods can also be supported.

> > 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.

Definately.

> > 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.

Yes, there is no reason why there can't be multiple Auth plugins.  My
goal is to build a simple but flexible system that can be plugged in
with little or no configuration.  It won't deal with external
authentication method like Basic Authentication or mod_perl auth
handlers, because by definition those are used outside of your
application.  So it doesn't make much sense to code for them.

> > 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.

I would like to try and stay away from any symbol table witchcraft if
at all possible.

> > 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.

I never actually looked at that bit of code, and now I notice that you
can call run_modes multiple times...  That makes things easier.  We
could actually call run_modes to see if the proper run modes are
there.  If not, add them in like this:

$self->run_modes({
   auth_login => \&auth_login_runmode,
});

That way we don't even need to worry about messing with the symbol
table as we are passing a code reference directly to the run_modes
method.

Does that sound plausible?

Cheers,

Cees

-- 
Cees Hek

---------------------------------------------------------------------
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