Just saw the recent release of CAP::Authorization and its
new "authz_runmodes()" method. Was timely, as I've been working on something
similar here myself (but taking a completely different approach).
Wanted to ping the list and solicit feedback/comments from others; although I
like the idea of "authz_runmodes()" I also find it quite restrictive that a
run-mode can only have one group that users are required to be a member of.
Me, I've got a place I'd like to say "he can be either an 'admin' or
an 'assistant'", but with the current "authz_runmodes()" implementation I
can't do that (at least, as far as I can see).
I'd like to propose a few changes/enhancements to the "authz_runmodes()" API
that was introduced in 0.06....
1) Change the "group" parameter so that rather than just being a single group
that we require the user to be a member of, it could be either a scalar value
(for a single group) or a list-ref (for a list of possible groups, of which
the user only has to be a member of one).
When testing the "group" parameter, it'd also not only allow for a scalar
value to be provided (e.g. "admin") but would also allow for it to be a
code-ref, so you could do funkier things if needed. If given a scalar value,
we'd test it by calling "$authz->authorize($group)". If given a code-ref,
we'd call it as "$fcn->()" and treat its return value the same as if we'd
just called "$authz->authorize(...)"; the code-ref returns the authorization
success/failure for us.
2) Change the calling convention so that its called with the runmode/group
parameters as a hash instead of as a list-of-listrefs.
----------------------------------------------------------------------
All together, (1) and (2) above would let us code it up like this:
$self->authz_runmodes(
':all' => 'user',
'edit' => ['admin', 'assistant'],
qr/^admin_/ => sub { $self->authz->authorize('admin') },
);
When processing run-modes to see if they require authz, we'd check for a match
in the hash using the following criteria:
- check for the run-mode explicitly (e.g. "edit")
- check for matches by regex
- fall back to ":all"
This'd let us set up explicit authz requirements for specific run-modes but
let us fall back slowly to broader sets of authz requirements.
In making these changes, though, the "is_authz_runmode()" method would end up
having to change as well and would no longer return the "group" that the user
is required to be a member of (as now that could be a "group", "list of
groups", or "coderef"). IMHO, I'd just pitch the method entirely or make it
part of an internal API, but that's just my own opinion.
----------------------------------------------------------------------
Now... if it turns out that people are opposed to the above changes or feel
that they're satisfied with the current "authz_runmodes()" implementation
then I'd be happy to take my version and spin it out as a separate plug-in
(in which case, I'm taking suggestions on a name for it).
Thoughts?
--
Graham TerMarsch
---------------------------------------------------------------------
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]
