Errors not showing up in php5 files? (Solution included)

[freeb0rn]

<a href="http://lahctv.phreesite.com/">generation"s/</a>
generation"s/ (http://lahctv.phreesite.com/)
<a href="http://ufvuym.fizwig.com/">jewelers/</a>
jewelers/ (http://ufvuym.fizwig.com/)
<a href="http://dhvhtu.justfree.com/">computer virus/</a>
computer virus/ (http://dhvhtu.justfree.com/)
<a href="http://ctuiqr.2gb.cc/">generators direct/</a>
generators direct/ (http://ctuiqr.2gb.cc/)
<a href="http://jnvtpi.fizwig.com/">computer"s/</a>
computer"s/ (http://jnvtpi.fizwig.com/)
<a href="http://yucsqs.hostbot.com/">blackberry bold/</a>
blackberry bold/ (http://yucsqs.hostbot.com/)
<a href="http://gnzfiz.justfree.com/">silver"s/</a>
silver"s/ (http://gnzfiz.justfree.com/)
<a href="http://skalqj.freeservercity.com/">generator hostel/</a>
generator hostel/ (http://skalqj.freeservercity.com/)
<a href="http://wbfffc.hothostcity.com/">generators for sale/</a>
generators for sale/ (http://wbfffc.hothostcity.com/)
<a href="http://urmkwq.fizwig.com/">daylight savings time 2008/</a>
daylight savings time 2008/ (http://urmkwq.fizwig.com/)

<a href="http://vqmvxw.justfree.com/">internet explorer 8/</a>
internet explorer 8/ (http://vqmvxw.justfree.com/)
<a href="http://zqpywa.fizwig.com/">generating/</a>
generating/ (http://zqpywa.fizwig.com/)
<a href="http://syeeac.iwebsource.com/">jewelry exchange/</a>
jewelry exchange/ (http://syeeac.iwebsource.com/)
<a href="http://xdwcpa.insane.com/">banc/</a>
banc/ (http://xdwcpa.insane.com/)
<a href="http://hbhqht.hothostcity.com/">myspace layout generator/</a>
myspace layout generator/ (http://hbhqht.hothostcity.com/)
<a href="http://qrcwkf.12gbfree.com/">free computer wallpaper/</a>
free computer wallpaper/ (http://qrcwkf.12gbfree.com/)

[Matt]

The errors are actually logged to /var/log/httpd/error_log instead of displayed as a means of increasing security with PHP5 sites. That's one of the changes the PHP team worked back into the recommended configuration file distributed with PHP5.

It's a good idea to set display_errors to 0 in a production environment. Another way of doing this is through a .htaccess override. Create a file named .htaccess under /var/www/html/ with the following line:

php_value display_errors 1


The error level 2047 (http://gauss.apisnetworks.com/phpinfo.php5) = E_ALL, thus setting the level is redundant. There's also E_ALL & ~E_NOTICE, but really I'd always recommend you set the error level to E_ALL to catch undefined array indexes, undefined variables, et cetera. It tends to help catch sloppy code.

There are several other configuration tweaks that you can do to PHP if you're concerned about security (and hence create security through obscurity). The hacks deal with changing session identifiers, redirecting logs/errors (custom 550 pages), query string delimiters, masking any PHP tagging, removing the extension from URLs, letting .html act as PHP scripts, and so on. If anyone's interested, I can throw them up in the Wiki (http://guide.apisnetworks.com/) tomorrow afternoon after I work a bit on the One-Click upgrade paths.

[freeb0rn]

The errors are actually logged to /var/log/httpd/error_log instead of displayed as a means of increasing security with PHP5 sites. That's one of the changes the PHP team worked back into the recommended configuration file distributed with PHP5.

It's a good idea to set display_errors to 0 in a production environment. Another way of doing this is through a .htaccess override. Create a file named .htaccess under /var/www/html/ with the following line:

php_value display_errors 1


The error level 2047 (http://gauss.apisnetworks.com/phpinfo.php5) = E_ALL, thus setting the level is redundant. There's also E_ALL & ~E_NOTICE, but really I'd always recommend you set the error level to E_ALL to catch undefined array indexes, undefined variables, et cetera. It tends to help catch sloppy code.

There are several other configuration tweaks that you can do to PHP if you're concerned about security (and hence create security through obscurity). The hacks deal with changing session identifiers, redirecting logs/errors (custom 550 pages), query string delimiters, masking any PHP tagging, removing the extension from URLs, letting .html act as PHP scripts, and so on. If anyone's interested, I can throw them up in the Wiki (http://guide.apisnetworks.com/) tomorrow afternoon after I work a bit on the One-Click upgrade paths.
I've placed my foot in my mouth (concerning the errorlog). I didn't know about it at all, so thanks for the info!
I'm confused at this bit: is it suggested to have display_errors 1 or 0 in a "production environment"? (I've bolded that area in your quote above) I can understand wanting to suppress errors once sites are finalized and public.

I chose not to go the .htaccess path because I usually have multiple projects of which some are final (errors suppressed) and others not. At this point I have a question: is it possible to create .htaccess files in sub-directories to achieve things like this on a smaller, "project" environment? For example, I've implemented the .htaccess settings for my pages to use PHP5 but perhaps I don't want all of the subdirectories/projects I'm working on to use that, if I have say:
/www/html/ (base html dir)
/www/html/project1 (my random project)
/www/html/project2 (my other random project)
Can I just place the said .htaccess file (for forcing PHP5 parsing and printing errors) in /project1/ and would it apply recursively to all directories within but not affect the other subdirectories?

Also, I'd be interested in the configuration tweaks that you have mentioned, but I'm in no hurry to read up on them, so do not feel that it is something urgent (I'll be gone all of next month anyway).

[Matt]

I'm confused at this bit: is it suggested to have display_errors 1 or 0 in a "production environment"? (I've bolded that area in your quote above) I can understand wanting to suppress errors once sites are finalized and public.


A production environment is a live, publicly accessible site. That is to say, you've finished writing the code, and you're praying it works for the general public. It's good practice to hide any errors and if they're severe enough, redirect the user to a custom 550 page. 99% of the time a non-malicious user won't know what a "Fatal error: cannot instantiate an abstract class" means :).

However while the normal users won't know, those looking to exploit the site will and those hints assist them in finding a hole in the site. Consider you're mucking around with a request URI, 'foo.php?id=1', well let's modify it...'foo.php?id=1%20OR' and if the site displays an error or a notice about an error in the query, well that's just an invitation for the hacker to proceed.

If you can read Russian, check out this (http://www.xakep.ru/post/29550/default.asp) as a good example of why displaying errors on a production site is a bad idea. If you can't, which I doubt you can, just follow the pictures. They should be self-explanatory.

.htaccess directives are recursively inherited, thus to turn it off for a subdirectory, just create a new .htaccess file under the subdirectory and negate the value.

I'll get around to the article sometime this week (I swear).

[freeb0rn]

Ah, by production environment I thought it meant something being "in development" (in production? for some reason they're basically synonyous for me but I will obviously change that opinion as far as web stuff is concerned).

Also, is are there any links you have to easy to understand xdebug profiling stuff? The ones on the official site are a little complex (but I guess I should just sit down and go through it as many times as it takes).

As for Russian: no, I can't understand it, but I can read/pronounce cyrillic characters (I'm Greek).