On Wed, 13 Oct 1999 [EMAIL PROTECTED] wrote:
>
> This seems to work fine for us. It meets the requirements you state as
> having the connection password in just one place as well.
>
> I personally dont think that putting the password into the environment is
> such a good idea. Too much potential for someone to steal it.
>
Also, not all web servers are kind enough to export the equivalent of
environment variables from a config file so it's not cross-webserver if
you ever switch to apache (unlikely) or more likely, you want to share
your code with a friend who has an alternateweb server.
I would tend to agree on the security stance. Although I think it is a bit
arguable. The issue for me is thatanyone breaking into the web server
with a rote script will be able to view the environment and figure out
what it means, but only a Perl programmer would be able to go into the
source code and pull out the connection information. It's not as easy. But
a person who hacks in and knows what they are doing will be able to get
the password regardless.
If you want to be more secure, then you use a middleware strategy so that
you create a restricted RPC or object server between the database and the
web server such that the db password is in the RPC server, and the web
server only has access to a restricted subset of RPC functionality. That
way, the hacker has to break both the web server and the mddleware server
to gt to your DB unprotected.
But as with all things, at some point thee are diminishing returns with
performance being the thig most hit by layered approaches (unless you
build fancy caching in your middleware).
Later,
Gunther
