On 6/21/05, Michael Graham <suppressed> wrote:
> 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.
Personally I think there are better ways to do that then with dynamic
method names.
> 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 {
> ...
> }
Why not just mark the runmode itself as requiring authentication using
the attributes.
sub my_runmode : RequireAuth('manager') {
}
I haven't done much with method attributes, but they always seem to me
to be a very powerful mechanism. Especially when dealing with META
data around subroutines (which is really what runmode level
authentication is).
> 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.
I am not really married to CGI::Session::Auth. When I first started
using it (about 2 years ago now I think), it looked like it had a lot
of potential. However, development of the module stagnated right
after I started using it (then again the development of my Auth plugin
stagnated as well so I guess I should talk :).
> 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.
CGI::Session::Auth is mostly an API that allows you to build an
interface to any datastore for your user names (remember
authentication might go to an LDAP database, and may be completely
separate from the rest of your data). What it does tie you down to is
CGI::Session.
With the plugins that I have built so far I have tried to avoid
writing a module that does X, and instead find a module that already
does X well, and make it work well with CGI::Application. So if
people want to scrap CGI::Session::Auth, I would be OK with that, but
I wouldn't want to write a Plugin that replaces its functionality.
I would rather see us use (or build) a generic Authentication module
that accepts a username and password, or an IP address, or some other
token to authenticate a user, and checks it against an arbitrary
datastore (where a datastore could be anything from a flat file to an
LDAP server or even a cookie or param sent from a centralized auth
server). I think there may already be a few modules like that on
CPAN, but I haven't looked in a while.
Once we have such a module we can write a nice clean wrapper to link
it into CGI::Application, but people could also use it in other
frameworks just as easily. I think it is the functionality of the
wrapper (or plugin) that we have really been taking about in this
thread.
Anyway, I'm glad to see some interest in getting the authentication
stuff moving again. I still haven't got the time to really focus on
it, but I'll help as much as I can...
Cheers,
Cees
---------------------------------------------------------------------
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
Mail converted by mhonarc 2.6.15
This archive provided courtesy of JSW4.NET, Internet Hosting Services for Small Business.