The only real security problem is that if the file isn't parsed and it's in the web server's document path, somebody can just go to http://www.example.com/include/config.inc and see the entire contents in plaintext -- passwords and config options galore. However, sticking those .inc files outside of the web server's document path or otherwise cutting off access to those files makes things a lot safer.
When I met Rasmus at a seminar a few months ago, he mentioned that he kind of started the whole ".inc" thing with included files, but he was astonished how so many people followed his convention without realizing that somebody could look into the .inc file so easily. When he was going it, he always explicitly denied access to those files through a <Files> directive in Apache's httpd.conf file, which nobody else bothered to do. So if you want people to view those files and all of the code in them, go nuts. Otherwise, you'd better somehow cut off access to them. (Personally, I use an include directory and use a .htaccess file to limit access.) J Erik Price wrote: > > On Friday, February 15, 2002, at 10:50 AM, Michael Kimsal wrote: > > Maybe I don't understand the security implications of .inc -- I thought > that it was perfectly safe. Since my php.ini is not configured to parse > files with '.inc' extensions, I thought that I was better off using a > separate extension than '.php': so that the code cannot be "executed out > of context". I got this idea from a post by Rasmus Lerdorf on this very > list, only a month ago. > > Erik > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
