Re: Best Practices for Hiding Errors
| From: | Igor Escobar | Date: | Tue, 07 Apr 2009 00:49:09 +0000 |
| Subject: | Re: Best Practices for Hiding Errors | ||
| References: | 1 2 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-291149@lists.php.net to get a copy of this message | ||
Becarefull, error supression is slow.
Regards,
Igor Escoar
Systems Analyst & Interface Designer
--
Personal Blog
~ blog.igorescobar.com
Online Portifolio
~ www.igorescobar.com
Twitter
~ @igorescobar
On Mon, Apr 6, 2009 at 8:38 PM, Chris <dmagick@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
> 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
>
>