Re: How to share schemas but varying table privileges (user/password)?

[prev] [thread] [next] [Date index for 2005/02/21]

On Sun, Feb 20, 2005 at 03:45:05PM -0600, Thomas L. Shinnick wrote:
> I've reviewed docs and maillist posts and seen several discussions of reusing classes/schemas across more than one database simultaneously.  My situation somewhat parallels those, though I'm hoping for a simpler answer or at least a "it won't hurt _that_ much."
> 
> I want to reuse the same classes, across different programs, but varying the DB/table privileges available via those classes.  This means that the user/password information for DBI connections would have to change from one program to the next, in order to vary the access privileges available to each program.  I see discussions of moving dbMain() higher in class hierarchies or playing with set_db() but they look rather painful.
> 
> Let me describe an example situation: three programs accessing a table of log information.  One program merely reads entries and generates reports.  One program tails a file and creates entries.  Another admin program requires full privileges such as deleting old records.  The desire is to allow each program only the least privileges it needs to run.
> 
> Each program could use the same CDBI-derived class for the table, however the usual scheme has the MyLogBase super class establishing the single user/password pair used to access the table.
> 
> Do I have to override dbMain() to force program-specific privileges?
> 
> Could I setup the usual DB-class -> table-class derivation, using the lowest priviledged user/password in the DB-class, and then do a set_db() later to get higher privileges?  How sensitive is set_db() timing?

How about having the apps set up so they set their connection property early
on via config? having the configuration stuff run as a BEGIN { } block will
ensure it happens before Class::DBI::Loader et. al. and should work fine.

        -- 
            Matt S Trout            Brag sheet:    http://trout.me.uk/services.html
LAMP, Infrastructure        Contact:       services@xxxxx.xx.xx
   and Automation
     specialist                                       Do it once. Do it right.