On Fri, 29 Oct 2004 11:16:30 -0400, Drew Taylor
<[EMAIL PROTECTED]> wrote:
> On Fri, 29 Oct 2004 16:31:40 +1000, Cees Hek <[EMAIL PROTECTED]> wrote:
> Nice. At $dayjob I have my own version of require_authentication(),
> but I haven't (yet) needed group authentication. I've thought of using
> Role-based authorization rather than groups because of the added
> flexibility. IMHO it makes it easier to mix-n-match various
> permissions with out going into group hell. But I admit to bias
> because that is how a previous employer did it and it allowed
> tremendous flexibility.
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.
A user can belong to as many groups as you want, and if you want, you
can dynamically create new group names on the fly.
> > So basically you have authentication and authorization on a per module
> > basis (it could probably be extended to do per runmode auth, but I
> > haven't needed that, and think it is probably a design/organizational
> > mistake to do so anyway).
>
> 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.
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.
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.
> > 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.
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.
Cheers,
--
Cees Hek
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
