Jerry, I think the way to make your code future version safe would be as follows: 1.) Derive a driver class from CGI::Application::Plugin::Authentication::Driver::DBI 2.) You will need to add an extra config parameter to represent the label of the driver. 3.) Override the "verify_credentials" method obviously letting SUPER::verify_credentials do its stuff . 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 . 4.) You then have the driver label available.
Nicholas [email protected] wrote: > Send cgiapp mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.erlbaum.net/mailman/listinfo/cgiapp > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of cgiapp digest..." > > > Today's Topics: > > 1. Multiple Authentications? (Nicholas Bamber) > 2. Re: Multiple Authentications? (Jerry Kaidor) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 09 Jun 2010 19:04:57 +0100 > From: Nicholas Bamber <[email protected]> > Subject: [cgiapp] Multiple Authentications? > To: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii; format=flowed > > 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" <[email protected]> >> Subject: [cgiapp] Multiple Authentications? >> To: "CGI Application" <[email protected]> >> Message-ID: >> <[email protected]> >> 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 >> [email protected] >> http://www.erlbaum.net/mailman/listinfo/cgiapp >> >> >> End of cgiapp Digest, Vol 33, Issue 8 >> ************************************* >> >> > > > > ------------------------------ > > Message: 2 > Date: Wed, 9 Jun 2010 12:51:59 -0700 (PDT) > From: "Jerry Kaidor" <[email protected]> > Subject: Re: [cgiapp] Multiple Authentications? > To: "CGI Application" <[email protected]> > Message-ID: > <[email protected]> > Content-Type: text/plain;charset=iso-8859-1 > > >> 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. >> > > *** Yes, I found the example, and coded my stuff up with four DBI drivers. > It seemed quite straightforward. Haven't tried it yet though. > > >> 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). >> > > *** I am going to use my own authorization stuff. It's there, it works > well. I already have something like 50 different permissions. I even have > a command line driven utility for adding permissions - it modifies the > database and the perl code. > > As for not remembering which driver authenticated - I'm looking at the > source of CAP:Auth to see about adding it. I would add an individual name > to each driver, passed at setup(), a variable to hold it, and a method > to get it. Plus something in my application to yell out if I should > inadvertently upgrade CAP::Auth from my modified version to a new improved > main line one without the feature :). > > - Jerry > > > > > > ------------------------------ > > _______________________________________________ > cgiapp mailing list > [email protected] > http://www.erlbaum.net/mailman/listinfo/cgiapp > > > End of cgiapp Digest, Vol 33, Issue 9 > ************************************* > ##### 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/ ## ## ## ################################################################
