but they give the following warning:
"This is a feature to support your development and should never be used on
production systems (e.g. systems connected to the internet)."
Am unclear what that means - is it okay to add:
It's about "information disclosure".
Errors/warnings/notices contain paths to php files when they are printed
out.
$ cat test.php
<?php
ini_set('display_errors', true);
error_reporting(E_ALL);
echo 'a is ' . $a . "\n";
$ php test.php
Notice: Undefined variable: a in /path/to/test.php on line 4
You don't want that because now a potential attacker knows some info -
it's a unix type system (a windows path is drive:\blah\folder so looks
different) and the files are located in /path/to/.
If that message contains database info or passwords for example, you
could be in trouble.
ini_set('display_errors','Off');
to my page, so that an end user won't ever get the warning displayed and I can deal with the error behind the scenes? Or is there a better way to keep PHP from writing error codes to the screen?
That's exactly the right thing to change - but only for production
systems. You should develop with this ON so you can see when you have a
problem that needs to be addressed. Some situations (as above) will
cause a problem as you've seen but most won't.
You can also use the @ symbol before the function name - but make sure
you don't use it everywhere (it'll make debugging extremely hard - you
could spend hours looking for a problem and it ends up being a database
connection problem) & also comment your code about why you're doing it:
# use the @ here because php throws a warning if it can't be opened.
$fp = @fsockopen('blah');
--
Postgresql & php tutorials
http://www.designmagick.com/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
