Where to store script configuration?

notset

Hello,

my web script has many settings. To one of them need a very high degree of security, to another - not. If i put all settings into mysql table, my script will use a lot of traffic by selecting the same data from db on every page load. If i put all settings in php file - it's unsecure and hard to change settings from admin panel. So, where to store web site configuration?

Thank you.

Installer

Try adding a column to the table that corresponds to the security level each row applies to. Then from your scripts do the query adding a WHERE term (e.g. "WHERE security_level = 'level_a'").

etully

A good web hosting company gives you a directory to work in and an htdocs directory that is your web tree that is exposed to the public. Putting text files in your directory ABOVE your htdocs directory is very secure.

If you need good security and your host doesn't give you space outside your web tree, you can use an htaccess file to make a directory invisible to web browsers... but frankly, that's not a web host I would want to use when security is important.

MySQL is no more or less secure than storing configs in text files. Each can be very secure and each can be exploited if you don't take precautions.

MarkR

Store all your application's settings in a config file if possible. This can be a .php file which contains constants set with define().

Nobody can read this file because the web server will execute it as PHP (it will do nothing) instead of viewing it.

But for extra security, put it in a subdirectory with

Deny From All

In .htaccess (This assumes you're using Apache).

If you've got stuff in there which is really commercially sensitive (or for that matter, if that is in your D😎, don't use shared hosting.

Mark

notset

Installer wrote:
Try adding a column to the table that corresponds to the security level each row applies to. Then from your scripts do the query adding a WHERE term (e.g. "WHERE security_level = 'level_a'").

Thank's for the great idea 🙂

MarkR wrote:
Store all your application's settings in a config file if possible. This can be a .php file which contains constants set with define().

Is define('SITE_URL', '') more secure than $settings['site_url'] ?

Twysted

i woud think so since your using a settings varible it tells someone where to look in the db the other way that does not happen.

Weedpacket

notset wrote:
Is define('SITE_URL', '') more secure than $settings['site_url'] ?

It's not really a matter of security as such (though if you store the information in a variable, there is a faint risk that coding errors will corrupt it and cause your sensitive bits to be exposed; trying to redefine a constant will cause the script to whinge and it will leave the constant unchanged).

Rather it's (partly) for the sake of performance and (mainly) for the sake of source legibility. Site config information doesn't change while the script is executing - it's constant. So it makes sense to use a language construct that represents constant values. Then when you read the source code you can see which values are constant (they're the constants) and which values are variable (they're the variables).

MarkR

On a side note: it is far better to make something automatically detected than to require a config variable for it.

For example, if there is any feasible way you can detect the site URL at runtime ($_SERVER['HTTP_HOST'] perhaps?), then you should do that instead.

It will make things easier when deploying code from dev -> staging -> production.

Having the least number of config options possible is definitely a good idea.

We put our application's config usually in a single .php file, which is the only part of the application not deployed from dev to production (Because obviously it needs to be different there).

Mark

Weedpacket

MarkR wrote:
For example, if there is any feasible way you can detect the site URL at runtime ($_SERVER['HTTP_HOST'] perhaps?), then you should do that instead.

For the best of both worlds, a trampoline script that does the autodetection and replaces itself with the generated config file.... file_put_contents(FILE, $stuff); is startlingly easy to do.

MarkR

Weedpacket wrote:
For the best of both worlds, a trampoline script that does the autodetection and replaces itself with the generated config file....

Hmm, self-writing code, eh? Sounds a bit like an antipattern to me.

Mark

Weedpacket

It's part of the deployment (and hence a one-off), so it's self-writing anyway 🙂 (I have to say I've never actually used it.)