7

Note: Configuration are being kept in a PHP file, config.php.

I've seen this done differently, here's a short list of examples (I'm storing DB info in these examples):

Constants: global, readonly

define('DB_USER','user12');
define('DB_PASS','21user');

Using GLOBALS array: global, changeable, repetitive, mixed with other globals

$GLOBALS['DB_USER']='user12';
$GLOBALS['DB_PASS']='21user';

Using a non-global array but raised globaly: possibly worse than the 2nd option

$config=array(); ...

$config['DB_USER']='user12';
$config['DB_PASS']='21user';

... global $config;
    mysql_connect('localhost',$config['DB_USER'],$config['DB_PASS']);

Defining class properties: (global, enumerable)

class Config {
    public $DB_USER='user12';
    public $DB_PASS='21user';
}

Criteria/Options/Features:

  • ease of coding: you wouldn't want to check if the setting exists, or initialize it
  • ease of modification: a non-programmer/layman could easily modify the settings
  • stored in a clean place: not mixed with other variables (can be stored in a sub-array)
  • runtime modification: in some cases, other devs may easily modify existing settings

The configuration might need to be changed some time during the running of the system, so option 1 is already not viable. The third option is not too clean either.


While writing this, I'm getting a big warning on the discussion being subjective and closed. So please keep up to the topic and give valid reasons to your answers.


This is a pretty obvious question, and considering I'm well familiar with different answers, you might ask, why am I making all this fuss? The thing is, I'm developing a framework, and unlike another framework (*ahem* joomla *ahem*) I don't want to pass through their mistake of throwing in a miss-informed solution which ends up having to be changed/re-purposed in the future.


Edit: First of, the location of the config file does not concern me. I'll make sure people can easily change location, if they want to, but this will not be a requirement. First of, cheap webhosts does not allow doing this, secondly, as far as security goes, this is really not a good option. Why? Because, the framework needs to know where the config is. Really, security through obscurity does not work. I'd rather fix all RFI and XSS (for instance) than be paranoid on hiding the config file under several layers.

Christian
  • 27,509
  • 17
  • 111
  • 155
  • 1
    possible duplicate of [What is the best way to store configuration variables in PHP?](http://stackoverflow.com/questions/593440/what-is-the-best-way-to-store-configuration-variables-in-php) – alex Oct 08 '10 at 06:22
  • `The configuration might need to be changed some time during the running of the system, so option 1 is already not viable` - doesn't sound like a very good system! The whole idea of a config file is that you define **constants** with general site settings like database settings, maybe page titles, etc. What sort of things are you storing that you might want to change? – chigley Oct 08 '10 at 06:23
  • Here's how it works: a PHP class, Database, operates on config constants DB_?, someone might want to write a script to sync two DBs (as an example), but is not able to use the Database class because he can't change the constants....ok this is a pretty lame example, I can't think of a better one. Hope you get the idea tho. – Christian Oct 08 '10 at 06:46
  • Alex, now that I see it, I agree, however the answer to it is not what I am seeking. Suggestions? – Christian Oct 08 '10 at 07:05
  • possible duplicate of [PHP, Reading File](http://stackoverflow.com/questions/2237291/php-reading-file) – Gordon Oct 08 '10 at 08:19
  • Gordon - Really, that is ridiculous. Do you mind actually contributing to the discussion? – Christian Oct 08 '10 at 08:49
  • 1
    @Christian I don't think you know what "security through obscurity" means. Making your config files publicly accessible and hoping people won't stumble across them, *that* is security through obscurity. – user229044 Oct 08 '10 at 14:40
  • meagar - I know perfectly what it means. I'm starting to think there's a distinct misunderstanding, since what I've been saying all this time is that a framework which might disclose a path to the config always makes it unsafe, whether the config is in the docroot or not. – Christian Oct 08 '10 at 15:47

4 Answers4

4

Hard-coded data may not be an option where people doing reconfiguration are not code-adept. Consider using parse_ini_file().

bcosca
  • 17,371
  • 5
  • 40
  • 51
  • The part about users not being code-adept is a REALLY good argument. However, I'm afraid of using ini files since they're downloadable, and of course, you wouldn't want people downloading a config file which contains your server's FTP details. :-) – Christian Oct 08 '10 at 06:58
  • Don't use the .ini file extension. Use something else instead. Or save the file in a non-Web-accessible path. – bcosca Oct 08 '10 at 07:02
  • Unless I hide the file via htaccess (many ways to do this, but it looks like a hack to me), the only viable option is a PHP extension with `[]` at the start of the file to stop the parser while still having a valid ini file - though again, this sounds like bad design/hack. – Christian Oct 08 '10 at 07:08
  • 1
    Why not store the main config file outside the exposed htdocs tree? Then use a stub config.php or ini that points to the correct config. – MadCoder Oct 08 '10 at 07:15
  • Also, Christian is right; relying of htaccess to hide security sensitive data is a bad idea. I've seen that fail; apache will happily serve up php and ini files as raw text. – MadCoder Oct 08 '10 at 07:17
  • MadCoder, would you use a CMS/framework if on of the intsall requirements would be what you are suggesting (file out of docroot)? I know I wouldn't, it "must be a very crappy framework if it has such a dumb requirement". – Christian Oct 08 '10 at 07:37
  • 2
    Security sensitive data should never be stored anywhere within docroot, period. I certainly wouldn't use a framework that made me work against it to follow the most basic security tennets. Taking security seriously would be a great way to distinguish yourself from the vast sea of PHP frameworks out there. – MadCoder Oct 08 '10 at 08:07
  • @christian-sciberras A crappy framework is one that doesn't care about security and forces you to have everything in the Web root. – bcosca Oct 08 '10 at 08:43
  • MadCoder - we both agree security is a priority, however, I see no need to get paranoid about it. Storing sensitive info in docroot or not is not really important since, if someone has script access, he can just as well include (read etc) files out of docroot, defeating the initial purpose. I see this option as "crappy" since there are way better alternatives, which allow for storing sensitive info in docroot. The point is, the framework needs to take into consideration that it might be **running anywhere** with **any kind of config** (with regards to htaccess etc). – Christian Oct 08 '10 at 08:54
  • stillstanding - As I said to MadCoder, taking security into affect does not mean limiting features or restricting use. If someone wants to run a website with this framework, he shouldn't be required to put everything out of docroot. – Christian Oct 08 '10 at 08:57
  • I find this security-related discussion mostly moot. I'm making sure the framework (and indeed, any following developers) follow security practices, however, getting paranoid about it does not help anyone. If people are so much afraid of docroot, might as well they run plain static html files, because, in all honestly, no matter how the framework is built, there's always the same amount of risk. If docroot is the hole, moving everything elsewhere won't help it. – Christian Oct 08 '10 at 09:00
  • Back again to what I'm calling "a crappy framework". Remember how we used to set up Apache? Do we all agree that setting apache isn't a piece of cake? Compare setting it manually VS using control panels (eg; EasyApache etc). Making installation easy doesn't have to compromise security - it just needs more thinking and planning. – Christian Oct 08 '10 at 09:01
  • If you're developing a "proper" framework, you shouldn't be using `define` or those `global` keywords either because they crap all over the global namespace. Storing user-configurable data in classes is not a good idea either. So you don't have too many options left. – bcosca Oct 08 '10 at 09:18
  • stillstanding - ...which is why I'm asking about this here? Yeesh give it a damn break will you? Wordpress uses DEFINES while Joomla used to use; DEFINES, GLOBAL VARIABLES and now a CLASS. – Christian Oct 08 '10 at 09:25
  • 1
    @Christian I've never seen a PHP framework that DOES let you store your config files under your doc root. I would absolutely avoid any framework that actually allowed you to do this, it's a terrible, awful idea. Storing config files in docroot is a terrible mistake. You can argue this point, but I have to wonder why you asked the question in the first place if you're going to disagree with the expert feedback you get. – user229044 Oct 08 '10 at 14:05
  • wordpress, joomla, or drupal as benchmarks for writing a better framework will not get u far enough. your framework will just be better than them but not the more robust ones where security is considered paramount :) – bcosca Oct 08 '10 at 14:15
  • meagar - That goes to show you don't use frameworks at all?! I just mentioned two of the most popular CMSes out there, which are arguably frameworks as well, that actually does put config in their docroot. – Christian Oct 08 '10 at 14:18
  • stillstanding - As I already said, what you and others propose is absolutely not an option. If someone wants to use an insecure server, there is nothing I can do to prevent intrusion, docroot or not. On the other hand, allowing people to store the config wherever they want, including NOT IN docroot, then it's fine by me. – Christian Oct 08 '10 at 14:20
  • meagar - That is absolutely NOT expert feedback. First of, I DID NOT ASK WHERE to save these configs, secondly I cannot see the reason behind the relentless shouting about a NON-ISSUE. As I said, if I am loading a config EVEN OUT OF DOCROOT, intrusion (eg, by the server spitting out TEXT FILES), CANNOT BE STOPPED. This is a FRAMEWORK ISSUE, and NOT AN OPTION. If someone wants to be secure against config file disclosure, THEY HAVE TO REFRAIN FROM USING ANY KIND OF FRAMEWORK. Now, if the Expert doesn't mind, I need the Expert's help at answering my damn question. – Christian Oct 08 '10 at 14:23
  • @Christian CMS and Frameworks are very different things. You're confusing the issue by calling them the same thing. Which are you trying to make, a CMS or a framework? Maybe wipe the froth from your lips and chill for a bit before you burst a vein. Also, protip: `@meagar` to reply and *stars* for *emphasis* rather than capitals. – user229044 Oct 08 '10 at 14:33
  • i have purposefully refrained from flagging this as a subjective discussion given the fact that the "best" solution is nowhere in sight and that the arguments nor the other solutions presented are acceptable to querent. i propose, at the least, that this be moved to community wiki, or at worst, closed. – bcosca Oct 08 '10 at 14:55
  • @meagar - A CMS is supposed to be a ready-made framework! Oh, and don't worry, I've had enough issues with other stackoverflow Experts so as to make vein-bursting a mild obstacle. – Christian Oct 08 '10 at 15:53
  • @stillstanding - How will "the best solution" ever surface if people don't even discuss the original question?? I wouldn't mind seeing this closed *after* we get to a conclusion -- Stackoverflow is there to help arrive to a conclusion not disintegrate questions which people don't know how to discuss. Just look at the sheer amount of replies, by 4 people, all about a *non-issue*. And time and again, the same people infect other parts of the discussion with the same unrelated subject. – Christian Oct 08 '10 at 15:55
2

Why not use Zend_Config? It creates a common interface for configuration options that can be stored in a confing file or a database (with a proper adapter). And it's lightweight; you don't have to bring in the entire Zend framework to use it.

BTW, since you're building a framework, you should keep pollution of the global namespace to a minimum. Something like your 3rd option, and if you're targeting 5.3 exclusively, look at using proper namespaces.

MadCoder
  • 1,344
  • 8
  • 7
  • I won't be using anyone else's framework. Plus, if they have their own config system which is good enough, I'm probably able to replicate it in my code. – Christian Oct 08 '10 at 06:57
  • +1 to your second paragraph, while at it, I'd like to mention that I'm not targeting 5.3+ – Christian Oct 08 '10 at 07:09
1

A bit late, but this might be of interest to you: http://milki.include-once.org/genericplugins/genconfig.html

It provides a simple API to edit PHP config files in-place. It keeps comments and other code in-tact. And it allows for a global $config array/ArrayObject and defining constants. It operates almost automatically if combined with plugin configuration comments. However, it's a lot of code. But maybe worth checking out for the concept. (I'm also using a readable config.php, as it seems the most useful configuration format for me.)

mario
  • 144,265
  • 20
  • 237
  • 291
0

Put in a common file and include it every where you need. The benefit when you go live or move to your test server you just need to edit just this one file and all configs are changed. Method 2 is better as it allows you to change it.

Remember once you connect to mysql if you need to change the user and pass you have to re-connect

aWebDeveloper
  • 36,687
  • 39
  • 170
  • 242
  • Sorry, didn't mention I'm already using the single-file-included-everywhere option...will update topic. – Christian Oct 08 '10 at 06:15