Page 1 of 1

What is best practice for global config variable?

Posted: Tue Feb 12, 2008 1:11 pm
by josamoto
I'm trying to tighten my PHP security as well as sharpen my coding practice a bit. My register_globals are ALWAYS off, and for hosted sites (those not on my production server) I have display_errors=Off; and expose_php=Off.

For most of my applications, I have a $config multi-dimensional array variable looking like the following example:

Code: Select all

$config['paths'] = array(
    'app' => 'Some Silly App',
    'nice-day' => 'most_certainly',
    'ice-cream-melts' => 'true',
    'lol' => 'you-bet'
);
Basically, I include the file containing this $config variable, but for every function I want to have access to it, I need the line:

Code: Select all

global $config;
Is it maybe better to write a static class and access $config like:

Code: Select all

$setting = $Config::app;
I don't feel extremely happy about using the global keyword, it looks like I'm asking for trouble, so my question is if there is a better way to have the $config variable available globally to all my classes/scripts within the application, SAFELY! I am very concerned about people hacking my code, so I want my "globals" to be airtight.

I am currently looking for more secure configuration, and have today written some code to prevent email header injection in my email wrapper class. I'll be taking action against SQL injection more seriously as well, and also using .htaccess more aggressively alongside setting up folder permissions on the web server.

Thanks for the help in advance!

Re: What is best practice for global config variable?

Posted: Tue Feb 12, 2008 2:14 pm
by Benjamin
Why not use constants, which are global in scope anyway?

Re: What is best practice for global config variable?

Posted: Tue Feb 12, 2008 3:14 pm
by Christopher
josamoto wrote:I don't feel extremely happy about using the global keyword, it looks like I'm asking for trouble, so my question is if there is a better way to have the $config variable available globally to all my classes/scripts within the application, SAFELY! I am very concerned about people hacking my code, so I want my "globals" to be airtight.
It is not the global keyword, but globals themselves that you should be unhappy about. ;) I would recommend trying to pass the config array, or a config object, into you functions before resorting to globals/statics. You also may want to think about passing in a Registry and registering things you create in the global scope (like config) that are needed within your application.

Re: What is best practice for global config variable?

Posted: Tue Feb 12, 2008 4:11 pm
by josamoto
Astions: I prefer not to use constants, as my array / static object application configuration approach allows me to group certain settings together, such as database settings, email settings etc. in a sub-array. This means I can access them like so (for me organizing variables like this becomes helpful when you are breakpoint debugging and watching variables, especially when the configuration grows larger):

Code: Select all

$x = Config::database->username;
$y Config::database->password;
Arborint: I understand then a class with static member variables is not good practice either, if I understand your post correctly. On the other hand, considering passing the array as a parameter to every single function that needs it seems a waste and not the best and most practical coding practice.

How do I register the array? If what you mention is using register_globals=On or using $GLOBALS or global, I've read many articles warning that it is very insecure and I'd rather not go this direction. I'm having heebie-jeebies on this one. Eek... :D

I'm actually considering the credibility of using a static object declared as such:

Code: Select all

class Config(){
     public static $macintoshIsCool = 'true';
     public static $iLoveChocolate = 'sometimes'
}
Then I can simply access it like:

Code: Select all

if(Config::$iLoveChocolate && Config::macintoshIsCool){
     // Do something outrageously silly...
}
Maybe one can come up with some solution for loading the Config class, once and once only, creating a checksum (for ex. MD5) across the entire setup, and using member functions (like Config::getILoveChocolate()) which would in turn check against the checksum whether the supposed to be read-only configuration has been altered or tampered with since its initial load.

Just an idea though. Maybe I'm totally :crazy: And surely that would cause some performance hit, but at the cost of better security, I think it's worth it. I am VERY paranoid these days.

My previous job apparently had their servers wiped two weeks in a row a few weeks ago due to lack of security, and I don't want this kind of thing to happen to me. They had about 300 websites hosted, and how it happened I don't know. I just know I'm going to take every step to try and keep my sites safe and my clients happy. I am NOT going to be victimized.