|Keep It Simple, Stupid|
Best practice with polymorphic constructorsby Ovid (Cardinal)
|on Sep 03, 2001 at 01:08 UTC||Need Help??|
Ovid has asked for the
wisdom of the Perl Monks concerning the following question:
I have a class, we'll call it Foo::Database, which is a base class for three other classes:
The Foo::Database class, amongst other things, connects to the database and controls all direct use of the DBI module. However, each of the child classes connects to the database as a different user. This is done for security reasons. I see no reason to give a Foo::Database::Select object the ability to modify the database if it doesn't need to. I view this as "defense in depth". If there's a security hole in another portion of code, hopefully the security built into the objects is a nice fallback.
Since I connect to the database in the constructor, the obvious idea is to make the constructor polymorphic by adding a unique constructor to each class. However, only the username and password for these constructors is unique and I didn't see the need to have repetitious code. This is what I used in the base class (well, there's more, but this is stripped down):
Note that all sensitive data is in a file (currently just a simple data structure) that's not Web-accessible. The problem that I don't like is that the config file now must have the module names hard-coded into it. As I wrote in a node about orthogonal code and security, I'm not wild about having to build something that requires different parts of a system to be synchronized. Any suggestions for improvement?
Vote for paco!
Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.