On 2003-03-18 02:15:25 -0500, Paul Boutros wrote: > And what are some of the better solutions to that? I've taken to > putting the entire DB connection syntax in a separate module so > that I have: > > use StandardModules::DB; > my $dbh = StandardModules::DB::connect_db(); > > That way passwords are both centralized (for regular changes) and not > present > in the script itself. But are there better solutions facilitated by > DBI itself?
You could set the environment variable DBI_DSN. I'm not sure whether you
can embed username and password for all drivers in that, though. And
anyway, on many Unix systems every user can see the environment
variables of all processes, so that would be a security hole.
I usually use variations of the following:
sub new {
my ($class, %opts) = @_;
my $self = {};
my $cred_file = $opts{credential_file} || $ENV{DBI_CREDENTIAL_FILE};
if (! defined($cred_file)) {
$cred_file = "$ENV{HOME}/.dbi/default";
} elsif ($cred_file !~ m{/}) {
$cred_file = "$ENV{HOME}/.dbi/$cred_file";
}
$self->{dbh} = DBI->connect(_read_cred($cred_file),
{ RaiseError => 1, AutoCommit => 0 });
[...]
}
sub _read_cred {
my ($fn) = @_;
open(FN, "<$fn") or die "cannot open $fn: $!";
my $line = <FN>;
close(FN);
my @cred = split(/[\s\n]/, $line);
return @cred;
}
The user running the script then needs to set up a file containing
$data_source, $username, and $password (readable only for himself) and point
DBI_CREDENTIAL_FILE to it.
hp
--
_ | Peter J. Holzer | Unser Universum wäre betrüblich
|_|_) | Sysadmin WSR / LUGA | unbedeutend, hätte es nicht jeder
| | | [EMAIL PROTECTED] | Generation neue Probleme bereit.
__/ | http://www.hjp.at/ | -- Seneca, naturales quaestiones
pgp00000.pgp
Description: PGP signature
