CMS - Deployable Zip and MySQL idea

--001636ed657cb063b10479f9667b
Content-Type: text/plain; charset=ISO-8859-1

For the fun (and experience) of it, I am building a PHP content management
system compatible with MySQL. I want to be able to drop a ZIP file into
someone's root folder, extract, and load the index file in the admin folder
is deploys.

I had that part worked out, redirect the user to a "Add MySQL Connection"
form if no MySQL database connection is available. I had pretty much all the
code in place when I realized,how am I going to add database connection
information through a webpage that isn't already manually connected?

Usually the login information for MySQL is hard coded into the PHP scripts.
How can I connect to a database without hard coding it?

Take a moment to think about how you would resolve this. I'm sure what I
came up with is probably not so elegant as what most of you will come up
with, but this is what I did.


I set up some logic at the beginning of admin/index.php to check for a
specific directory in the root folder (called "_spin"), if it returns false
(as it is supposed to the first time admin/index.php is run), it creates the
folder with 0750 permissions (to make it private). Next it creates a text
file called KEY.txt in that new directory with the string "temp", and then
redirects to the database add form (any attempt to directly call the .txt
file results in a 404).

If the file KEY.txt is found in the directory _spin, it reads it to get the
database connect credentials. At the database add form, KEY.txt is opened
and "temp" is replaced with the POST(ed) data (host, username, password,
database name). After KEY.txt is saved, these values are also added to a
site_settings tables (which is created at the same time).

Now in the future, the database connection profile can be deleted but still
maintain connection, or conversely, the KEY.txt file can be unlink(ed) to
effectively start over (at which point the database tables can optionally be
dropped simultaneously).

And for error handling, the initial logic checks the contents of the text
file so if find anything besides "temp" as the first item (contents exploded
as CSV variables with spaces as the seperator), so your server cannot be
named exactly "temp", it uses the CSV variables as the mysql_connect()
parameters ("localhost username password dbname" is put into $conn[0],
$conn[1], $conn[2], and $conn[3]).

So are there any obvious security flaws with this?

Is this a method that others use or did I come up with something unique?

--001636ed657cb063b10479f9667b--

Re: CMS - Deployable Zip and MySQL idea

--=-KlyQUllAXJfO5fdEdtsW
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

On Sat, 2009-12-05 at 03:19 -0800, Allen McCabe wrote:

> For the fun (and experience) of it, I am building a PHP content management
> system compatible with MySQL. I want to be able to drop a ZIP file into
> someone's root folder, extract, and load the index file in the admin folder
> is deploys.
>
> I had that part worked out, redirect the user to a "Add MySQL Connection"
> form if no MySQL database connection is available. I had pretty much all the
> code in place when I realized,how am I going to add database connection
> information through a webpage that isn't already manually connected?
>
> Usually the login information for MySQL is hard coded into the PHP scripts.
> How can I connect to a database without hard coding it?
>
> Take a moment to think about how you would resolve this. I'm sure what I
> came up with is probably not so elegant as what most of you will come up
> with, but this is what I did.
>
>
> I set up some logic at the beginning of admin/index.php to check for a
> specific directory in the root folder (called "_spin"), if it returns false
> (as it is supposed to the first time admin/index.php is run), it creates the
> folder with 0750 permissions (to make it private). Next it creates a text
> file called KEY.txt in that new directory with the string "temp", and then
> redirects to the database add form (any attempt to directly call the .txt
> file results in a 404).
>
> If the file KEY.txt is found in the directory _spin, it reads it to get the
> database connect credentials. At the database add form, KEY.txt is opened
> and "temp" is replaced with the POST(ed) data (host, username, password,
> database name). After KEY.txt is saved, these values are also added to a
> site_settings tables (which is created at the same time).
>
> Now in the future, the database connection profile can be deleted but still
> maintain connection, or conversely, the KEY.txt file can be unlink(ed) to
> effectively start over (at which point the database tables can optionally be
> dropped simultaneously).
>
> And for error handling, the initial logic checks the contents of the text
> file so if find anything besides "temp" as the first item (contents exploded
> as CSV variables with spaces as the seperator), so your server cannot be
> named exactly "temp", it uses the CSV variables as the mysql_connect()
> parameters ("localhost username password dbname" is put into $conn[0],
> $conn[1], $conn[2], and $conn[3]).
>
> So are there any obvious security flaws with this?
>
> Is this a method that others use or did I come up with something unique?


I think what most systems do in this case is to use a config text file
like you've mentioned. You can have PHP allow a user to enter the DB
credentials and test them to ensure they work. If they do, create the
correct DB structure, and write the config details to a file.

You will need to secure this file against people looking it up though.
One way might be to chmod it so that the 'others' cannot even read it.
You could create it as a PHP file so that only the PHP scripts on the
same server would be able to return the list of variables within. One
last thing could be to put it in a directory protected with a .htaccess
file. This will reject people trying to browse the directory without the
correct credentials, but will still allow your own scripts to read the
file.

Thanks,
Ash
http://www.ashleysheridan.co.uk



--=-KlyQUllAXJfO5fdEdtsW--