Becarefull, error supression is slow.
Systems Analyst & Interface Designer
On Mon, Apr 6, 2009 at 8:38 PM, Chris <dmag...@gmail.com> wrote:
> 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
> $ cat test.php
> ini_set('display_errors', true);
> 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.
>> 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
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php