Storing user name and password for MYSQL

[big-dog1965]

I think I seen it some where but cant find it again
Is there a way to store
$username="name";
$password="password";
$database="mydatabase";
that is used to access MYSQL from a PHP page
in a seperate file and have the PHP page get it from there when needed.

[tech_support]

Here's a good place to start.

[boogyman]

you could store them in an xml file?

[Twey]

The common way of doing it is storing them in a PHP file as variables, then including it.

[big-dog1965]

The common way of doing it is storing them in a PHP file as variables, then including it.

Can you give excample of how to do it

[codeexploiter]

You can learn how to include files in a PHP file here

dbop.php
<?
    require_once("dbconfig.php");    
?>

dbconfig.php
<?
    $dbuser = "root"; //Mention the database user who can access the database and perform the operations in your case.
    $dbpassword = "somepassword";    
?>

[tech_support]

$dbuser = "root"; 

Ouch. Never ever ever use root to do logins or anything to do with databases when the pages are going to be viewed on the internet. If a hacker gets into your site, and finds out your root password through your page, consider your database gone.

If you created separate accounts in MySQL with different privileges, the most damage a hacker could do is delete all your accounts (That's if you set the privileges to allow to delete)

[Twey]

I usually do it this way because I like to use a $_CONFIG array. However, if you only have primitive values to store it would be simpler to use defines:

define('DBUSER', 'root'); // Why the heck are you using the root account?
define('DBHOST', 'localhost');
define('DBPASSWORD', 'somepassword');

mysql_connect(DBHOST, DBUSER, DBPASSWORD);

If you use global variables in a function, you have to worry about writing

global $dbhost, $dbuser, $dbpassword;

all the time. Defines remove the necessity for this.

[jmctg]

Also, do not (is that clear enough?) DO NOT store your username / password in anything but a .php page (or a page which the server will parse as php if it is accessed.)

The reason for this is simple. A few years ago, there was a silly fad to simply use *.inc for an include file. As you can see, this is not secure...

View a couple of these, and presto! you have the database username, password and table names...

be very, very careful where you store those variables.

[djr33]

I was going to post a similar reply to boogyman's suggestion of xml. Very bad idea.
It would store it fine and be accessible, but it would not be secure at all.

Using .php (and variations) is the only way to go, since php is secure in itself, and you are using it anyway. You could, in theory, store it some other way, but the necessarily piece is that php can use the data, so might as well make that the only way to hack it. If you use two methods, it just doubles the odds against you, not to mention that if your PHP isn't secure, there's no real point to it anyway. (Generally php should be secure, unless you have a security flaw in a script.)


the trend for .inc is kinda weird, though in some cases can be a nice distinction.
Clearly, it's not secure, and a bad idea as such, with these exceptions:
1. Use it for nonsecure code (ie some function that doesn't really give anything away about your system). //shrug... probably not the best idea.
2. Configure your host to treat .inc as a php parsed extension, and it will become secure.
3. I like, in some cases, using .inc.php, since it does differentiate, but keeps it as .php.