Re: Security with dbHost, dbUser, dbPassword

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




----- Original Message ----- From: "Jochem Maas" <jochem@xxxxxxxxxxxxx>
To: "Satyam" <Satyam@xxxxxxxxxxxxx>
Cc: <php-general@xxxxxxxxxxxxx>; "Otto Wyss" <otto.wyss@xxxxxxxxxx>
Sent: Thursday, January 11, 2007 12:16 AM
Subject: Re:  Security with dbHost, dbUser, dbPassword


Satyam wrote:

----- Original Message ----- From: "Otto Wyss" <otto.wyss@xxxxxxxxxx>

What is the usual save way to store/use DB access info in a script. I
currently just use some PHP variables in a file which I include in all
other scripts.

config.php
<?PHP
  if (!defined ("config_include")) die ("Error...");
  $dbhost = "localhost";
  $dbuser = "name";
  $dbpass = "password";
  $dbname = "database";
  $dbcoll = "utf8_unicode_ci";
?>

Is this save enough or are there better ways? Where should I store
this file so it isn't accessible via the net but inside scripts?

O. Wyss


Besides what Jochem has already sugested, I would add that I usually
have in the include file, in an unaccessible path as he said, a function
that returns a connection. The function has all the connection
information local, so that they are neither global variables nor
constants, just local literal values within the function.

I'm sure most people end up with some kind of abstraction in the form
of a class or function to do all the 'heavy lifting' regarding connecting
to the DB, etc - but when projects get rather large and/or your faced with a
situation where you want/need to run your project on different systems
(e.g. local-dev, test/staging, live) it often most handy to place all installation
specific configuration values in a single file that is specific to the
given installation and therefore usually not included as part of the
version control (e.g. CVS or SVN) module that stores the projects files.

No problem there, the include in my DB abstraction layer includes and calls the separate file with the function to make the connection to the database. Though the main application source doesn't know about the include file with the connection data in it, the DB layer include does. In this way, I have the db include file under CVS and can refresh it at the production server without a problem, while the include file with the connection is separate, so that I have one for the test machine (this one) where the server is 'localhost' which I never copy to the production server.

Nevertheless, I admit that the important issue here is to have the connection data out of the public folders, mine is just a useless paranoid complication. Does anyone have an expression evaluator in an application open to the public? Does anyone make a var_dump of $_GLOBALS on error (and then forgets to strip it out on production code)? I sure hope not.


In the same
function I put the call to mysql_select_db.  Though I check the return
values for errors, I usually ignore them since unless you have either
more than one database engine or more than one database, the default
link resource does not need to me explicitly passed to other functions.

Satyam



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux