View Full Version : htaccess - protecting files outside public_html

03-30-2010, 02:14 PM
I'm trying to take extra measures to protect my MySQL password.

As it stands, the password is stored in a php variable outside public_html, in a folder with a .ini.php extesion:


Given its location on the server, am I right in saying the following addition to my .htaccess would be redundant, or could it still help?

<Files *.ini>
Order deny,allow
Deny from all

More generally, is there anything more I could do to help keep this password secure, given that MySQL won't accept a hashed password?


03-30-2010, 09:47 PM
It is always good to store configuration files in a private directory like you have done, good work. Renaming it to .ini.php should avoid it being served up by the webserver, but nobody can access in the first place, so hey-ho.

I say keep that directive in your .htaccess or even your main vhost config if possible - I can't imagine any situations where you would actually want to serve a .ini like a normal file.

03-30-2010, 10:11 PM
Thanks. Useful comments.

Just one point to clarify:

Does the htaccess "deny from all" that I'm using mean that any files ending in ".ini" that are entered manually into a URL will be denied? Have I understood that correctly?

If so, then isn't it the case that my config file isn't accessible via a URL anyway (given that it's not in public_html), so even without the htaccess directive, nothing could be entered into the URL that could result in its been parsed in the first place?

03-30-2010, 10:16 PM
The directive "deny from all" in that configuration means that any .ini file that someone requests, will result in the in the webserver sending a HTTP 403 and not the file. This stops anyone should they type the URL or click a link.

I mention in my previous post, might as well leave the directive (even though it is technically not doing anything - your file is in a private directory and cannot be accessed) because it will stop anyone getting the file should you accidently put .ini files in a public directory in the future.

03-31-2010, 12:37 AM
Got it.

All very clear now.