SYNOPSIS
use DBIx::Password;
my $dbh = DBIx::Password->connect($user);
my $dbh = DBIx::Password->connect_cached($user);
$dbh->getDriver;
DBIx::Password::getDriver($user);
DBIx::Password::checkVirtualUser($user);
DBIx::Password::clearConfig();
DBIx::Password::readConfig("$ENV{HOME}/.my.secret.file");
DESCRIPTION
Don't you hate keeping track of database passwords and such throughout your scripts? How about the problem of changing those passwords on a mass scale? This module is one possible solution. It stores all your virtual users and data in /etc/dbix-password.conf. For each user you need to specify the database module to use, the database connect string, the username and the password. You will have to give a name to this virtual user. You can add as many as you like.I would recommend that if you are only using this with web applications that you change the final permissions on this package after it is installed in site_perl such that only the webserver can read it.
A method called getDriver has been added so that you can determine what driver is being used (handy for working out database indepence issues).
If you want to find out if the virtual user is valid, you can call the class method checkVirtualUser(). It returns true (1) if the username is valid, and zero if not.
Once your are done you can use the connect method (or the connect_cache method) that comes with DBIx-Password and just specify one of the virtual users you defined while making the module.
BTW I learned the bless hack that is used from Apache::DBI so some credit should go to the authors of that module. This is a rewrite of the module Tangent::DB that I did for slashcode.
If your program does not need the system-wide information stored in the /etc/dbix-password.conf file, you may use the clearConfig() and readConfig() functions to get the data from another source. At any time, readConfig() may also be used to merge the data from another file into the currently-loaded configuration.
Hope you enjoy it.