sfox Mon Jan 31 07:53:29 2005 EDT
Modified files:
/phpdoc/en/security errors.xml
Log:
Getting rid of the E_NONE myth, and also incorporating a user note.
http://cvs.php.net/diff.php/phpdoc/en/security/errors.xml?r1=1.6&r2=1.7&ty=u
Index: phpdoc/en/security/errors.xml
diff -u phpdoc/en/security/errors.xml:1.6 phpdoc/en/security/errors.xml:1.7
--- phpdoc/en/security/errors.xml:1.6 Thu Aug 12 21:00:48 2004
+++ phpdoc/en/security/errors.xml Mon Jan 31 07:53:28 2005
@@ -1,5 +1,5 @@
<?xml version="1.0" encoding="iso-8859-1"?>
-<!-- $Revision: 1.6 $ -->
+<!-- $Revision: 1.7 $ -->
<!-- splitted from ./index.xml, last change in rev 1.66 -->
<chapter id="security.errors">
<title>Error Reporting</title>
@@ -100,7 +100,13 @@
By testing your code, prior to deployment, with E_ALL, you can
quickly find areas where your variables may be open to poisoning
or modification in other ways. Once you are ready for deployment,
- by using E_NONE, you insulate your code from probing.
+ you should either disable error reporting completely by setting
+ <function>error_reporting</function> to 0, or turn off the error
+ display using the &php.ini; option <literal>display_errors</literal>,
+ to insulate your code from probing. If you choose to do the latter,
+ you should also define the path to your log file using the
+ <literal>error_log</literal> ini directive, and turn
+ <literal>log_errors</literal> on.
<example>
<title>Finding dangerous variables with E_ALL</title>
<programlisting role="php">
