Richard Nuttall wrote:
  - support for automatically pulling database DSN information from a
    ~/.dbi (or similar) file.  This is constantly re-invented poorly.
    Let's just do a connect by logical application name and let the
    SysAdmins sort out which DB that connects to, in a standard way.
This reminds me one one thing I hate about DB access, and that is having the DB password
stored in plain text.

Sadly, there is really nothing that can be done about this, other than
"casual" obscuring of the real password like CVS does in ~/.cvspass

However, making it in a file in $HOME/.xxx means that the sysadmin can
set it up to be mode 400 or something like that, to ensure other users
can't access it if someone forgot to set the permissions right on the
application code (or, hopefully, configuration file).

Of course, for more secure access schemes like kerberos, etc, the file
is really just being a little registry of available data sources.

On a similar note could be allowing overriding the data source used by
an application by setting an environment variable.  That way, the
SysAdmin has got lots of options when it comes to managing different
production levels - Oracle has this with TWO_TASK, and while it's a
PITA when it's not there (no doubt why DBD::Oracle allows this to be
specified in the DSN string), it's also useful for what it's intended
for - switching databases from an operational perspective.


Reply via email to