On Tue, May 31, 2005 10:55 am, Leif Gregory said: > Hello Martin, > > Sunday, May 29, 2005, 9:24:00 PM, you wrote: > M> I saw files like "file.inc.php" and "file.inc" > M> What is the *.inc suffix good for ? > > It's good for a lot of trouble if the webserver hasn't been set up to > parse .inc files as PHP. If it hasn't then someone can request that > file in a broswer and see the code. Gak! It's good for even *MORE* trouble if the webserver is set up to parse .inc as PHP! You've got files that people can get executed *COMPLETELY* out of context, that *NOBODY* even though about being executed out of context, much less *TESTED* in any kind of QA process! I can surf to http://example.com/admin.inc and who knows what will happen if that PHP code in there gets executed without all the code you expected to be executed before that code? > I'd just stay away from using .inc for an include and do either of the > below: > > config.inc.php > > or just > > config.php Neither of which solve the base problem: The *REAL* solution is to put your .inc files *OUTSIDE* the web-tree where they simply CANNOT be executed out of context (by surfing to them) and cannot be downloaded by Bad Guys looking for holes. You can also add code to the beginning of every .inc file which attempts to examine the state of the HTTP request to determine that it is not being called out of context, but that's a pain to have to put in every file, or to have to remember to include the include file that does that, and to hope that every developer (or even just you) remembers to do that. It's really much easier to just fix your include_path, move the files where they cannot get accessed, and be done with it. Just my opinion. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
