Closed Thread Icon

Topic awaiting preservation: suggestions for php config file (Page 1 of 1) Pages that link to <a href="http://ozoneasylum.com/backlink?for=12580" title="Pages that link to Topic awaiting preservation: suggestions for php config file (Page 1 of 1)" rel="nofollow" >Topic awaiting preservation: suggestions for php config file <span class="small">(Page 1 of 1)</span>\

 
bitdamaged
Maniac (V) Mad Scientist

From: 100101010011 <-- right about here
Insane since: Mar 2000

posted posted 01-16-2003 23:53

Alright so I mentioned my bitblog thing on the main board a while ago and I'm running into this problem.

Right now all my config settings are in a php file where all the settings are in an associative array, this file is read and then creates a bunch of constants used by my scripts. Now the reason I did it this way is so that it's relatively easy to manipulate and since it's a php file that doesn't echo anything, if it's put outside the document root directory and if someone navigates to it they just get a blank page (ideally it would live outside the httpdocs folder and just accessed via script but this isn't always an option).

Now the problem is that I'm writing an install script which would ask for how the user wants these config options set and then "set" the variables and save them to the file. However In my admin screen I also want the user to change the settings so I'd be opening, reading and writing to the file.

Now that's all well and good but I'm worried about the file getting read properly since it's in an array format with many many coments any of which may hit a regular expression used to parse it. This would be easier with just a comma seperated flat file however that runs into some security issues since it could be outside the doc root and if it wasnt' a php file (or the data was outside the delimeters) it could be read by anyone.

I'm thinking of putting this data in the database which would save some hassles but that seems like too much over head for what would be one row of data. (plus the db config vars like database hostname etc would still need to be somewhere).

I dunno I'm thinking of sticking with the way things are right now. But I was just wondering if anyone else had some ideas.



.:[ Never resist a perfect moment ]:.

[This message has been edited by bitdamaged (edited 01-16-2003).]

genis
Paranoid (IV) Inmate

From: Dallas, TX
Insane since: Aug 2002

posted posted 01-17-2003 00:41

"I'm thinking of putting this data in the database which would save some hassles but that seems like too much over head for what would be one row of data."

It'd be less overhead than a flatfile.

Tyberius Prime
Paranoid (IV) Mad Scientist with Finglongers

From: Germany
Insane since: Sep 2001

posted posted 01-17-2003 11:33

it would be more overhead than a flatfile!
Especially if you wanted to have comments as well.

First, there's no problem naming any file either .htsomething (which an apache server will not deliver via http) or maybe something.cgi, which will usually fail with a 500 Server Error (the asylum actually stores it's user data that way)

Option a) Store the array with serialize() into a file
-pro: terribly easy. Fast to read. Easy to manipulate. Even easier to write out.
-drawback: a bitch to edit by hand, although it is doable

Option b) Write a script that stores the array into 'php code', and adds the comments as necessary (of course, you'd need another array that contained an array of array('fieldname','comment') to put the comments back in. To get the data, just include the file. afterwards just run it through your translation script again.

-Pro: Can be maintained by hand and code. Outputs nothing but ''.
-Con: you need that translation script. Users may put stuff into the config file that doesn't belong there, it get's overwritten if it's not in the script that does the settings.

option c)
combine the two. write a php file that contains $myConfig = @unserialize('%%the_serialized_array%%').
-pro: user never sees anything from that one
if $myConfig is false, there is a definate problem with the config there.
-Con: Hard to edit by the user, any direct modifications that are not caught by your config script (ie. are outside the defined fields) get lost on the next rewrite.

so long,

Tyberius Prime

« BackwardsOnwards »

Show Forum Drop Down Menu