php: hiding full paths in error messages

Hi, I'm trying to get this set of directives working in an .htaccess file, so that any time my PHP has an error, the full path to the file is NOT shown to the user's browser:

php_flag display_errors off

Ideally I'd get these two directives working as well, but that's secondary to the display_errors directive:

php_flag log_errors on
php_flag error_log "myerrors.log"

I've put these 3 lines in an .htaccess file, chmod'd so the server can use it, and have a script that intentionally triggers a fatal error, plus a few warning just for fun. This script still shows errors with the full paths though. I've also made a wrapper around phpinfo() PHP function, and looked at the "local" setting for "display_errors" which I would expect to be set to "off", but it's still "on".

Any ideas? Is there some setting I need to have enabled in my hosting plan so that these php_flag directives have an effect? Is there some other directive magic that I need to have in my .htaccess file? Do I need an .htaccess at the root of my web server (this one I'm trying to get working is a couple directories down from the root of my domain) that has something to enable .htaccess futher down in the directory tree? I couldn't find anything related to this in the wiki or these forums.

Thanks!

Hi,

Found this via http://uk2.php.net/ini_set

To change settings from .htaccess files, it is also required that the directory permissions configured in Apache allow this.

The <Directory /foo/bar> entry in httpd.conf MUST contain "AllowOverride All" or at least "AllowOverride Options" to read PHP settings from the .htaccess file.

E.g. in Fedora Core 2, the default settings for /var/www/html/ are "AllowOverride None", so changing PHP settings via .htaccess for applications installed below /var/www/html/ will not work.

May be a start...

You can only use PHP directives in .htaccess if you're using mod_php, which is not the default. To set these options while using PHP-CGI, use ini_set().

ini_set() works the vast majority of the time, but there are times when it doesn't get a chance to run before there is some other failure. For instance, say a require() fails. Or a parse error. Or some bizarre thing I can't think of...any of these will still print more info than I'd be willing to show to any random person visiting my site.

Am I just out of luck here? My real problem is that my last name is in the username I picked, so maybe I'll just create another user for myself with a different name, and run the web stuff from that user's account.

Thanks for the replies.

So the simple answer is to make sure it runs first. Put your calls to ini_set() all in a single file, then @require() that file first.

BTW, prepending a @ to your include() or require() calls will suppress the output, regardless of the display_errors setting.

Still no luck....

$ cat init.php
<?
ini_set('display_errors', 'off');
ini_set('log_errors', 'on');
ini_set('error_log', 'error.log'):
?>
$ cat test.php
<?
@require('init.php');

$foo = 'missing semicolon'
echo $foo;
?>

Browsing to test.php still shows:

Parse error: syntax error, unexpected T_ECHO in /home/.parade/foo/bar.com/test.php on line 5

In reply to:

---

Still no luck....

$ cat init.php
<?
ini_set('display_errors', 'off');
ini_set('log_errors', 'on');
ini_set('error_log', 'error.log'):
?>
$ cat test.php
<?
@require('init.php');

$foo = 'missing semicolon'
echo $foo;
?>

Browsing to test.php still shows:

Parse error: syntax error, unexpected T_ECHO in /home/.parade/foo/bar.com/test.php on line 5

---

You really can't stop PHP from complaining about outright errors in programming syntax; that colon at the end of line 4 in "init.php" will always cause you problems and subsequently cause the PHP interpreter to display the syntax error.
As Kenn pointed out, the simple answer is to make sure that your code doesn't have this particular sort of "gotchya" before putting it into a "live" environment. Create yourself a subdomain (ie. test.yourdomain.com) and get the blatent glitches out of your code *before* exposing it to unwashed masses of the Intarweb.