26

I need to store a bunch of configuration information in PHP.

I have considered the following....

// Doesn't seem right.
$mysqlPass = 'password'; 

// Seems slightly better.
$config = array(
     'mysql_pass' => 'password'
);

// Seems dangerous having this data accessible by anything. but it can't be
// changed via this method.
define('MYSQL_PASSWORD', 'password'); 

// Don't know if this is such a good idea.
class Config
{
    const static MYSQL_PASSWORD = 'password';
}

This is all I have thought of so far. I intend to import this configuration information into my application with require /config.inc.php.

What works for you with regard to storing configuration data, and what are best practices concerning this?

alex
  • 479,566
  • 201
  • 878
  • 984

4 Answers4

7

I've always gone with option #2 and just ensure that no one but the owner has ANY sort of access to it. It's the most popular method among PHP applications like Joomla, vBulletin, Gallery, and numerous others.

First method is too messy to me (readability) and the third is WAY too dangerous to do. I've never thought about the Class method, so someone else can provide their input on that one. But I guess it's fine so long as the right access is used on the class' usage.

Example..

define('EXAMPLE1', "test1"); // scenario 1
$example2 = "test2"; // scenario 2

function DealWithUserInput($input)
{
   return eval($input);
}

Now this example of code is really dumb, but just an example. Consider what could be returned by the function depending on which scenario the user could try to use in their input.

Scenario 2 would only cause an issue if you made it a global within the function. Otherwise it's out of scope and unreachable.

William Holroyd
  • 3,344
  • 1
  • 21
  • 25
  • Is it dangerous in the way that if some user input comes in with MYSQL_PASSWORD it might be passed with the actual password? – alex Feb 27 '09 at 04:06
  • That would be what could happen if you follow the second method you listed. It essentially sets it as a global variable, viewable in any scope. You can choose how classes or functions can access the $config array, so as long as you don't have it visible in the wrong scope, you should be fine. – William Holroyd Feb 27 '09 at 04:22
  • Edited post to give an example on two different ways you could have stuff defined in your code and how the user could get the information. – William Holroyd Feb 27 '09 at 04:30
  • Thanks for that, I posted a bit more to my question too. – alex Feb 27 '09 at 04:45
  • 8
    Doing an eval on user input is dangerous regardless of whether or not you've defined a constant. Can anyone provide another example of how defining constants is "WAY too dangerous"? – chyne Feb 27 '09 at 14:24
  • I agree with chyne. The vulnerability lies with eval-ing user input, not in having a global variable. Not globaling sensitive data mitigates the risk, but the real vulnerability is the eval. – GloryFish Feb 27 '09 at 21:26
  • I agree with the eval() comments above as well. Thats why I commented "Now this example of code is really dumb, but just an example.". Just oversimplified and improbable example of what could happen. But to me, the MySQL password should never be defined as a constant, visible to everything. There... – William Holroyd Feb 28 '09 at 00:23
  • ...shouldn't be a reason for it to be that accessible. It's like assuming everyone coming in the front door of an office building is responsible and has purpose for being there - so there isn't a reason to lock offices and labs inside the building. It should only be visible to the code that uses it. – William Holroyd Feb 28 '09 at 00:26
  • Actually, I've looked into the Joomla I've used, and their config is stored in a class. – alex Apr 02 '09 at 06:01
4

I'd say it also depends of userbase a bit. If configurations has to be very user friendly or user has to have ability to change config via web etc.

I use Zend Config Ini for this and other settings are stored in SQL DB.

raspi
  • 5,962
  • 3
  • 34
  • 51
1

I generally use the second method... When handling database connections I generally open a connection at the beginning of the request, then close it at the end. I have a function that establishes the connection, then removes the username/password from the global array (with the unset() function), This prevents other parts of the system from accessing the "sensitive" mysql connection data.

Jim OHalloran
  • 5,859
  • 2
  • 37
  • 57
0

I'm also with option 2 for most config values. If you were going to implement the Class then I would tie the specific values to the Class that it affects instead of a general config Class.

In your example, your Class would be for database connections and an instance would save the password, db_name, etc. This would encapsulate the data properly and also provide an easy means to create multiple connections if that was ever needed.

Paulo
  • 4,275
  • 2
  • 20
  • 20
  • Yeah that is true, except when you'd like to edit one file to be able to change any config data, then constants attached to a Db class will make it more difficult than a single access point (which is what I want) – alex Feb 27 '09 at 05:23