Re: [cgiapp] ANNOUNCE: CGI::Application::Framework (pre-release)

[Michael Graham <suppressed>]

> > Cees's Auth plugin allows for runmode level authorization as well as
> > just basic authentication. You can set it up so that anyone can view
> > runmode_a, but only "managers" can view runmode_x.
>
> Coming at this from a Catalyst perspective, I like the way
> Catalyst::Plugin::Authorization::CDBI (
> http://search.cpan.org/~mramberg/Catalyst-Plugin-Authentication-CDBI-0.06/CDBI.pm)
> does it. You have a user, role, and user_role table. The authorization looks
> at the user only. When you want to do role-based auth, you call
> $c->roles('required_role') which returns bolean. I imagine it would be
> pretty easy to have a standard method, say ${rm}_role(), which would return
> a list of role(s) required for the given runmode. If this method doesn't
> exist, the runmode is wide open. If the method is defined, the auth system
> would take the role(s) required for the runmode, query your user object for
> the roles it has defined, and see if the two match. If so, then the user is
> allowed in. Is this clear?

This is somewhat similar to what CAP::Auth does:

     $self->require_authorization({
       mode1 => 'admin',
       mode2 => ['admin', 'manager'],
     });

I do like the idea of having a magically named method return the
auth requirements for a given run mode.  That allows you to specify the
auth info right next to the run mode itself in your source code.

The only issue I see is that typos are potentially much more dangerous.
If you make a typo in CAP::Auth's require_authorization call you'll get
a runtime error.  But if you make a typo in a magic 'rm_roles' sub,
you'll just silently open up your run mode to the world.  Maybe some
protection could be provided with attributes a la CAP::AutoRunmode:

    sub rm_roles : Runmode_Auth {
        ...
    }

Then you could throw an error if there are Runmode_Auth subs that don't
have a matching Runmode sub.

I also like your suggestion for $user->has_roles, although this does
sort of force a Class::DBI approach.

On the other hand, CAP::Auth defers to CGI::Session::Auth for role
membership which means that it sort of forces you to use the 
CGI::Session::Auth database schema.

Personally, I'd like to avoid forcing the user to use any particular
data model.  So maybe it would be would be possible to define the roles
check within in the application itself (or the project)?  I.e.

    $self->user_has_roles($user, @roles);


That way, you could use your Class::DBI objects if you want to, or even
skip the database entirely and store your users and groups in the config
file.

> sub rm_foo { return "This is FOO" }
> sub rm_roles { return ('manager') }
> sub _caf_auth {
>     my $self = shift;
>     my $role_method = $rm.'_roles';
>     my $user = $self->get_user_object.
>     if ($self->can($role_method)) {
>         my @roles = $self->$role_method();
>         unless ($user->has_role(@roles)) {
>             $self->current_runmode('noauth');
>         }
>     }
> }

Another consideration is that it would be nice to eventually be able to
define more complicated access rules with boolean logic.

So maybe the per-runmode auth method does the check itself?  For example:

    sub publish_article_auth : Runmode_Auth {
        my $self = shift;
        my $user = shift;

        return unless $user;  # must be authenticated!

        return (
            $self->user_has_roles($user, 'user', 'editor')  # must have both
            &&
            (
                # could be manager or supervisor - same thing
                $self->user_has_roles($user, 'manager')
                ||
                $self->user_has_roles($user, 'supervisor')
            )
        )
    }


However maybe this puts too much power (and potential runtime errors) in
the hands of the actual runmode?


Michael




-----------------------------------------------------------------------
Michael Graham <suppressed>

YAPC::NA 2005 Toronto - http://www.yapc.org/America/ - suppressed
-----------------------------------------------------------------------



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