Tim,
We subclassed DBI for the purpose of putting in our own connect handler.
This connect handler reaches out to a password server and retrieves the
password and then calls SUPER::connect. This has worked out very well
for us. The purpose was to prevent scripts from having passwords hard
coded and to secure the server's administrative ids. The connect
handler we coded checks for host name, suid and effective suid. We then
pass this info to the password server and if the host/suid/effsuid login
is allowed, the password is returned. Otherwise an error is returned.
We also coded the handler to act as a pass thru when a password has been
supplied. This resolved a lot of security issues for our particular site.
Subclassing was the perfect approach for solving this issue.
In terms of problems, finding out the exact elements that had to be
subclassed required a bit more reading than it should have, but after a
few days I was comfortable with what had to be done and implemented it
in a very short period of time. The current documentation in DBI now has
the critical info about the handles that need to be subclassed. The
other big issue I had was with Sybase and the lack of dependencies built
into their libs. This caused me no end of frustration, but was not a
DBI issue.
I am not sure how it could have been done better. When we went to
convert over to the new DBI we had created, it was a simple as scanning
scripts for DBI and changing that name to the new module name.
Great Job on DBI, Looking forward to DBI2.
Chuck Fox
Principal Database Administrator
America Online.
[EMAIL PROTECTED] wrote:
I'm interested to hear stories of people who have subclassed the DBI,
or used modules that subclass the DBI.
Was subclassing the DBI a good approach?
Where there any problems?
Could it have been done well/better some other way?
Thanks!
Tim.
