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/ ## ## ## ################################################################