[cgiapp] Multiple Authentications?

[Nicholas Bamber]

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" <jerry at tr2.com>
> Subject: [cgiapp] Multiple Authentications?
> To: "CGI Application" <cgiapp at lists.openlib.org>
> Message-ID:
> 	<3544e006eabdd6392534177e71aff063.squirrel at 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 at lists.openlib.org
> http://lists.openlib.org/mailman/listinfo/cgiapp
>
>
> End of cgiapp Digest, Vol 33, Issue 8
> *************************************
>