<p>As long as Apache and PHP are working like they’re supposed to, this is fine. Files that end in .php should always get processed by PHP before they’re served to the client.</p>

<p>Here are the risks:</p>

<ul>
<li>If PHP is ever disabled, or the server is misconfigured so .php doesn’t get processed by PHP, then Apache will start serving that file directly, exposing all of your code (and in this case, your DB credentials).</li>
<li>Every PHP file that gets loaded after index.php will be able to see those constants, and potentially echo them out. (Most likely this would be your own doing, e.g. you might be echoing out everything from <a href="http://php.net/manual/en/function.get-defined-constants.php" rel="nofollow">get_defined_constants()</a> while trying to debug something.)</li>
</ul>

<p>If you can live with those, go for it. Personally, I’d say it’s just not worth it.</p>

CC BY-SA 3.0
2014-10-28T21:58:39.197Z
Thanks Brandon for your comments, I'll be following your advise :)
crawf
CC BY-SA 3.0
2014-10-28T14:51:16.320Z
2014-10-28T14:56:32.727Z
2014-10-28T14:56:32.727Z
Brandon Kelly
<p>I've got a multi-environment setup similar to the following, and thinking about adding database details to the index.php. In this way, I can pretty much just edit the index.php when creating new websites - staying out of app/config.</p>

<pre><code>switch ($_SERVER['SERVER_NAME']) {
    case 'local.craft.dev':
        define('CRAFT_ENVIRONMENT', 'local');
        define('CRAFT_DB_USER', 'root');
        define('CRAFT_DB_PASSWORD', 'craftycraft');
        define('CRAFT_DB_DATABASE', 'local');
        break;
    case 'staging.com':
        define('CRAFT_ENVIRONMENT', 'staging');
        break;
    default:
        define('CRAFT_ENVIRONMENT', 'production');
        break;
}
</code></pre>

<p>Would there any potential security issues with this? I imagine being in the web root might be risky - but would having this information in db.php a level up really made a difference to a hacker?</p>

<p>Would like to hear your thoughts!</p>

CC BY-SA 3.0
2014-10-28T13:16:18.093Z
Before we go any further, I think it might be necessary for you to explain what you're trying to accomplish by staying out of 'app/config'.
Wes Rice
CC BY-SA 3.0
2014-10-28T13:18:39.707Z
Currently only need to edit index.php (for domain names) and db.php for database connections for each new install. While yes - it's only two files to edit, just wanted to be able to define this stuff in one place. Call me lazy if you will!
crawf
CC BY-SA 3.0
2014-10-28T13:34:26.517Z
I'm no security expert by any means, but my understanding is that being outside of web root makes a huge difference.
Douglas McDonald
CC BY-SA 3.0
2014-10-28T13:37:35.777Z
And that's what I was thinking - certainly don't want to sacrifice security for convenience. Can't hurt to ask :)
crawf
CC BY-SA 3.0
2014-10-28T21:58:02.253Z
I'd steer away from doing this in index.php simply because there is a documented way of doing this in 'app/config'. If you think of bringing more people into this project, it would be an irregular practice that wouldn't necessarily be clearly evident, which can cause confusion and problems. If you're the only developer, that is fine, but this is not a practice I'd recommend to anyone else reading this issue.
Wes Rice
<database><multi-environment><security>
Define database details in index.php
# Define database details in index.php

(Asked by: username_0 on 2014-10-28)

I've got a multi-environment setup similar to the following, and thinking about adding database details to the index.php. In this way, I can pretty much just edit the index.php when creating new websites - staying out of app/config.
switch ($_SERVER['SERVER_NAME']) {
    case 'local.craft.dev':
        define('CRAFT_ENVIRONMENT', 'local');
        define('CRAFT_DB_USER', 'root');
        define('CRAFT_DB_PASSWORD', 'craftycraft');
        define('CRAFT_DB_DATABASE', 'local');
        break;
    case 'staging.com':
        define('CRAFT_ENVIRONMENT', 'staging');
        break;
    default:
        define('CRAFT_ENVIRONMENT', 'production');
        break;
}

Would there any potential security issues with this? I imagine being in the web root might be risky - but would having this information in db.php a level up really made a difference to a hacker?
Would like to hear your thoughts!

**Tags:** database, multi-environment, security

> **Comments:**
> **username_1**: Before we go any further, I think it might be necessary for you to explain what you're trying to accomplish by staying out of 'app/config'.  
> **username_0**: Currently only need to edit index.php (for domain names) and db.php for database connections for each new install. While yes - it's only two files to edit, just wanted to be able to define this stuff in one place. Call me lazy if you will!  
> **username_2**: I'm no security expert by any means, but my understanding is that being outside of web root makes a huge difference.  
> **username_0**: And that's what I was thinking - certainly don't want to sacrifice security for convenience. Can't hurt to ask :)  
> **username_1**: I'd steer away from doing this in index.php simply because there is a documented way of doing this in 'app/config'. If you think of bringing more people into this project, it would be an irregular practice that wouldn't necessarily be clearly evident, which can cause confusion and problems. If you're the only developer, that is fine, but this is not a practice I'd recommend to anyone else reading this issue.  

---

## 1 answers

### Answer by username_3 on 2014-10-28. Score: 2 | Accepted answer

As long as Apache and PHP are working like they’re supposed to, this is fine. Files that end in .php should always get processed by PHP before they’re served to the client.

Here are the risks:

* If PHP is ever disabled, or the server is misconfigured so .php doesn’t get processed by PHP, then Apache will start serving that file directly, exposing all of your code (and in this case, your DB credentials).
* Every PHP file that gets loaded after index.php will be able to see those constants, and potentially echo them out. (Most likely this would be your own doing, e.g. you might be echoing out everything from [get\_defined\_constants()](http://php.net/manual/en/function.get-defined-constants.php) while trying to debug something.)

If you can live with those, go for it. Personally, I’d say it’s just not worth it.

> **Comments:**
> **username_0**: Thanks Brandon for your comments, I'll be following your advise :)  

---

