Modifying cdbi's default SQL and mod_perl

[prev] [thread] [next] [Date index for 2005/01/14]

I've been using Class::DBI for the past year in
every project that accesses a database, and it's
dramatically improved the quality of my applications.
It's one of those packages like CGI::Application
that just feels right if you've been doing Perl
development for a while.  Nice work.

Enough gushing--on to my question.  I recently made
a design choice that on the surface works beautifully,
but doesn't seem to be safe under mod_perl, and I'd
just like to verify that this is true.

I had to implement an Access Control List.  I don't
think much detail is needed here, but essentially
I created a table for groups, users, memberships
(the table that maps users to groups) and finally
an ACL table in which each record contains a 
class name, key for the actual object, permission
and a group ID.  There's a bit more to it, but
you get the idea.

By hand, the SQL can be constructed in such a way
that if you know the group IDs that a user is a
member of, you can join the ACL records with the
object records and come up with only the records
that the user is allowed to access.  Of course,
the group IDs aren't known until runtime.

So, I created an init_acl() method in the classes
that needed to be protected, and once the user's
session is loaded, a call to init_acl() with the
user's gids, REPLACES THE DEFAULT 'Retrieve' and
'RetrieveAll' STATEMENTS, so that all subsequent
calls are prefixed with the ACL join.  This works
great under CGI, and seems to be the perfect solution,
because it's transparent to Class::DBI and doesn't
subvert any of the work that Class::DBI is doing.

However, under mod_perl, the init_acl() calls
do conflict.  I probably wouldn't have noticed this,
but admin users skip init_acl(), and I noticed that
their results were limited by whoever set 'Retrieve'
and 'RetrieveAll' last.  It seems that Ima::DBIs
class/statement list is global.  I tried turning off
prepare_cached() in the set_sql() call, but that didn't
solve the problem.  I've searched for a definitive
answer, but I haven't run across it.

I'm sure this is a quick one--sorry for the long
winded buildup.

Thanks,
Pat