Hello, I've spent the last couple days working with the Auth plugins that Cees Hek was kind enough to share.
I have a proposed redesign of the Authentication DBI driver, with implications for other parts of the API as well. Cees will be primarily interested in this feedback, but input from others is welcome as well. The current docs are here: http://search.cpan.org/~ceeshek/CGI-Application-Plugin-Authentication-0.07/lib/CGI/Application/Plugin/Authentication/Driver/DBI.pm First, quick "before" and "after" snapshots, and then some commentary. Before: TABLES => ['user', 'domain'], JOIN_ON => 'user.domainid = domain.id', COLUMNS => { 'crypt:user.password' => '__CREDENTIAL_2__', }, CONSTRAINTS => { 'user.name' => '__CREDENTIAL_1__', 'lc:domain.name' => '__CREDENTIAL_3__' } After: SQL => sub { my $cred = shift; sql_interp("SELECT password FROM user JOIN domain ON (user.domainid = domain.id) WHERE user.name = ", \$cred->{user_name}," AND domain.name = ", \lc $cred->{domain_name}); } POST_DB_PROFILE => { constraint_methods => { password => my_crypt(); } }, The Authentication plugin should not really be in the business of SQL generation or filters and constraints, for which there are already nice general solutions that can play nice. In my example, I use SQL::Interpolate's sql_interp for an easy solution with clear SQL. By using the CREDENTIALS arrayref declared elsewhere, we can have clear variable names instead of '__CREDENTIAL_3__'. Also, filters are now applied easily through third parties. This beats creating a whole module to re-implement "lc"! I would leave SQL generation up to the user, but use SQL::Interpolate in examples because it's so easy. For constraints applied after the database query, we now use a familiar Data::FormValidator profile. As a special case, required/optional don't need to be specified. behind the scenes we'll use CREDENTIALS to form the input hashref. Constraints made for Data::FormValidator can now work here for greater re-usability. Beyond these issues, my other major suggestion is to move the 'protected_runmodes' and 'is_protected_runmode' to the Authorization module, where they seem to belong conceptually. Other perspectives? Mark -- http://mark.stosberg.com/ --------------------------------------------------------------------- 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]
