Re: [cgiapp] Multiple Authentications?
Hi Nicholas,
Jerry,
I think the way to make your code future version safe would be as follows:
*** OK, I'm working on it.
1.) Derive a driver class from
CGI::Application::Plugin::Authentication::Driver::DBI
*** I created a file inside the same directory as DBI called MULTI_DBI.pm.
At the top it says:
--- snip
package CGI::Application::Plugin::Authentication::Driver::MULTI_DBI;
use strict;
use warnings;
use base qw(CGI::Application::Plugin::Authentication::Driver::DBI);
--- endsnip ---
2.) You will need to add an extra config parameter to represent the
label of the driver.
snip
=head1 SYNOPSIS
use base qw(CGI::Application);
use CGI::Application::Plugin::Authentication;
__PACKAGE__-authen-config(
DRIVER = [ 'MULTI_DBI',
DBHS= [
'DBH_JOE' = $self-global_dbh,
'DBH_BOB' = $self-dbh1,
'DBH_BILL' = $self-dbh2,
#( etc for all DBHs )
]
TABLE = 'user',
CONSTRAINTS = {
'user.name' = '__CREDENTIAL_1__',
'MD5:user.password' = '__CREDENTIAL_2__'
},
],
);
endsnip
3.) Override the verify_credentials method obviously letting
SUPER::verify_credentials do its stuff .
*** I iterate through my anonymous hash of names and dbh's. For each
one, I stuff the dbh into %options{ DBH } and call
__SUPER__-verify_credentials.
You need to capture the output of the SUPER call. On failure just pass
back failure. On success stash the driver label
using perhaps CGI::Application::param or perhaps
CGI::Application::Plugin::MessageStack .
*** How about I just stuff the matched label back into the options hash?
It's accessible from both the driver and the application. And it wouldn't
affect your code at all.
- Jerry Kaidor
# CGI::Application community mailing list
####
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
####
[cgiapp] Multiple Authentications?
Jerry, The answer to your title question is yes - you can have multiple DBI drivers. There is an example in the main documentation where there are two Generic drivers and that should carry across. However I don't think this will quite do what you want. First of all the authentication module does not handle authorization (i.e. permissions). So according to CAP::Authentication every user is either authenticated or not and every page is either protected or unprotected. Authorization should govern access to specific objects which is a much more vague problem. There is a CAP::Authorization module but I have never looked at it. Secondly the code does not remember which driver finally authenticated the user. Message: 1 Date: Tue, 8 Jun 2010 11:50:40 -0700 (PDT) From: Jerry Kaidor je...@tr2.com Subject: [cgiapp] Multiple Authentications? To: CGI Application cgiapp@lists.erlbaum.net Message-ID: 3544e006eabdd6392534177e71aff063.squir...@www.jm-properties.com Content-Type: text/plain;charset=iso-8859-1 Hello, I see that CAPAuthentication will let you install multiple drivers. Can one install multiple instances of the same driver, only with different parameters? Here's my situation: My business has three locations - let's call them locA,locB,locC. The database for each location has a users table which contains usernames, MD5 passwords, and a constellation of permissions for each user. There is also a global users table. Its structure is exactly the same as the users tables for the individual locations. The permissions in this table apply to ALL the locations. So if user Bob appears in the global table and has permission foo, then inq_can_foo( Bob ) returns TRUE for all the locations. If, OTOH, Bob appears in LocA, then inq_can_foo(Bob) will only return TRUE if we happen to be in locA's web page. I'm thinking that I could register four DBI drivers, one for each database. Then the system would just try each users table until it got a match. I don't think it would scale well, though. But it would get things going for now, and with all of the authentication stuff buried in one or two files, I could easily change it in the future. After authentication - for the duration of the session - I would have to remember which database the user authenticated against, because that effects the permissions. - Jerry Kaidor p.s. I have gotten my entire project under Subversion, generated a branch for this work, and had a great time yesterday removing all the print statements from my HTML-generating code. Svn's method of doing branches - just create a separate directory for each one - seems rather hokey - but as long as it can reliably do merges, I guess I don't care. -- ___ cgiapp mailing list cgiapp@lists.erlbaum.net http://www.erlbaum.net/mailman/listinfo/cgiapp End of cgiapp Digest, Vol 33, Issue 8 * # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
[cgiapp] Multiple Authentications?
Hello, I see that CAPAuthentication will let you install multiple drivers. Can one install multiple instances of the same driver, only with different parameters? Here's my situation: My business has three locations - let's call them locA,locB,locC. The database for each location has a users table which contains usernames, MD5 passwords, and a constellation of permissions for each user. There is also a global users table. Its structure is exactly the same as the users tables for the individual locations. The permissions in this table apply to ALL the locations. So if user Bob appears in the global table and has permission foo, then inq_can_foo( Bob ) returns TRUE for all the locations. If, OTOH, Bob appears in LocA, then inq_can_foo(Bob) will only return TRUE if we happen to be in locA's web page. I'm thinking that I could register four DBI drivers, one for each database. Then the system would just try each users table until it got a match. I don't think it would scale well, though. But it would get things going for now, and with all of the authentication stuff buried in one or two files, I could easily change it in the future. After authentication - for the duration of the session - I would have to remember which database the user authenticated against, because that effects the permissions. - Jerry Kaidor p.s. I have gotten my entire project under Subversion, generated a branch for this work, and had a great time yesterday removing all the print statements from my HTML-generating code. Svn's method of doing branches - just create a separate directory for each one - seems rather hokey - but as long as it can reliably do merges, I guess I don't care. # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
