![]() |
Most efficient way of storing database configurations?
So i have 3-4 databases which I need to access within the same application. I know I should be storing the database configurations in a config.php file (which I have). The way I'll be accessing these is when I create a new database object, I'd like to specify which credentials to use.
So essentially, I'd like to be able to do something along these lines: PHP Code:
Thank you. :) |
ok, im guessing all you DB's are on the same server?
In the factory have the function mysql_select_db(), that is provided they are on the same server, thus the link identifier (created from mysql_connect function) will work. Just something i thought of off the top of my head. |
I don't follow.
My config.php file also has to have the info (username, password, ...) to connect to several databases. And not all databases are located on the same server. ;) |
right, then i think you will need a new link identifier then, my original thought was that you have the same server but with different DB's, then my example would work.
ill have a think about that, need to find a source of coffee to get my brain working. |
;)
I've played with the Zend Framework for a bit. And the way it seems to handle it is by putting the their configuration settings into an array, then loading it into the registry. Then when you need a connection, you simply use the registries get method. |
Why not load your config settings into a multi dimensional array?
For example: PHP Code:
PHP Code:
|
I have like this...
php Code:
So you just do like this to call it: php Code:
All those variables are set in the config.php And what you can do then, is to make a script that loads the database name from a .txt file And then another script that allows you to change that value. So your $tanaxia['config']['database']['data'] would be the value of the string in the .txt file ;) Piece a cake :) or not xD But that's the idea anyways. |
Sounds good, I'll put them in associative arrays. :)
|
Quote:
If you put the database name or any information like that in a text file make sure with .htaccess (for apache) or otherway (for other servers) that the file is not accessible to users. |
My config files are not in the root directory, so that shouldn't be a problem. And I always make sure to lock those directories with .htaccess. :)
|
Quote:
|
alternatively just name your config file with the .php extension, then the contents is hidden from the user.
But if the config is outside the root and locked then it should be ok i reckon |
Maybe you could get some use for the function:
http://se.php.net/manual/sv/function.parse-ini-file.php |
One downside with the INI file approach is that if somebody directly visits that file, it won't be parsed as PHP and thus show the MySQL credentials in all their beauty. You will need to be quite up with the htaccess file configuration in order to consider such an approach, that way you can prevent access to the INI file.
|
Quote:
Guess in that case you could tell your htaccess file to redirect any requests to *.ini . :) |
Yep. The best technique is to pretend as though the file does not exist. Use the same type of request, such as 301 move, regardless of whether or not they've found the correct config file, or a file that doesn't exist. That way they will never know, unless of course they crack your code - which still makes it tougher, if they've found a config file or not.
|
WildHoney, It's like you read my mind because that it exactly how I was going to approach it. :)
|
This is good! :-) Just ensure that you use the same kind of redirect. That will only matter if somebody is determined to crack your code as they will need to read the HTTP headers to deduce the type of redirect. There are a whole array of redirects - such as 301 redirect is the one most people will be aware of if they've touched upon SEO before, but it doesn't matter which one you choose as long as you're consistent.
|
Using a 301 means that the resource does exist but it is to be found at another location. I'd prefer a 404 (not found) error to be produced.
|
A 404 is not bad if you customise your errors, but if you remain consistent with whichever you decide to go for, then you'll have no problems. Redirecting would simply redirect back to the home page.
|
| All times are GMT. The time now is 07:57 AM. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.
Search Engine Optimization by vBSEO 3.1.0