Following methods are available to limit the amount of resources available to PHP through php.ini
A. Limit the amount of memory a script can consume
B. Limit the maximum execution time of a script
Following methods are available to limit the amount of resources available to PHP through php.ini
A. Limit the amount of memory a script can consume
B. Limit the maximum execution time of a script
The following can prevent PHP from being able to open a file on the hard drive
A. File system permissions
B. File is outside of open_basedir
• The PHP directive file_uploads must be set to On
• The form’s method attribute must be set to “post”
• The form’s enctype attribute must be set to “multipart/form-data”
Limit the files that can be accessed by PHP to the specified directory-tree, including the file itself. This directive is NOT affected by whether Safe Mode is turned On or Off.
When a script tries to access the filesystem, for example using include, or fopen(), the location of the file is checked. When the file is outside the specified directory-tree, PHP will refuse to access it. All symbolic links are resolved, so it’s not possible to avoid this restriction with a symlink. If the file doesn’t exist then the symlink couldn’t be resolved and the filename is compared to (a resolved) open_basedir .
open_basedir can affect more than just filesystem functions; for example if MySQL is configured to use mysqlnd drivers, LOAD DATA INFILE will be affected by open_basedir . Much of the extended functionality of PHP uses open_basedir in this way.
The special value . indicates that the working directory of the script will be used as the base-directory. This is, however, a little dangerous as the working directory of the script can easily be changed with chdir().
In httpd.conf, open_basedir can be turned off (e.g. for some virtual hosts) the same way as any other configuration directive with “php_admin_value open_basedir none”.
Under Windows, separate the directories with a semicolon. On all other systems, separate the directories with a colon. As an Apache module, open_basedir paths from parent directories are now automatically inherited.
The restriction specified with open_basedir is a directory name since PHP 5.2.16 and 5.3.4. Previous versions used it as a prefix. This means that “open_basedir = /dir/incl” also allowed access to “/dir/include” and “/dir/incls” if they exist. When you want to restrict access to only the specified directory, end with a slash. For example: open_basedir = /dir/incl/
The default is to allow all files to be opened.
Note:
As of PHP 5.3.0 open_basedir can be tightened at run-time. This means that if open_basedir is set to /www/ in php.ini a script can tighten the configuration to /www/tmp/ at run-time with ini_set(). When listing several directories, you can use the PATH_SEPARATOR constant as a separator regardless of the operating system.
A race condition or race hazard is the behavior of a software where the output is dependent on the sequence or timing of other uncontrollable events. It becomes a bug when events do not happen in the order the programmer intended.
Race conditions can occur especially in multithreaded or distributed software programs.
• Userland code may trigger custom errors
trigger_error( "something went wrong", E_USER_WARNING);
• These errors may be handled with a custom error handler function
function myHandler($code, $text, $file, $line) { if ($code == E_USER_WARNING) { echo 'WARNING: ' . htmlspecialchars($text); return true; } return false; }
• If the custom error handler function returns true, php´s error handling does not kick in
• Custom error handler function needs to be registered using set_error_handler(“myHandler”).
Example
<?php function myErrorHandler($errno, $errstr, $errfile, $errline) { echo "<b>Custom error:</b> [$errno] $errstr<br>"; echo " Error on line $errline in $errfile<br>"; } set_error_handler("myErrorHandler"); $test=2; if ($test>1) { trigger_error("A custom error has been triggered"); } ?>
• By default, all errors included in error_reporting are reported in php´s output
• This behavior can – and should – be deactivated on production systems using the display_errors = off php.ini setting
• Errors should still be logged, using the log_errors = on php.ini setting
• The error log is a file set in the error_log php configuration setting. if set to syslog, errors are logged in the system log independent on the operating system used.
• PHP supports several types of errors
o notices at runtime
o errors during parsing (prevents code execution)
o warnings at runtime
o fatal errors at runtime (stop code execution)
o Core errors and warnings
o user-defined notices, warnings, and errors
• php configuration setting error_reporting, or php’s error_reporting() function may be used to define which kinds of errors shall be reported
• Value is an integer, or – much more convenient – a bitmask based on pre-defined constants
o E_NOTICE, E_PARSE, E_WARNING, E_ERROR
o E_CORE_WARNING, E_CORE_ERROR
o E_USER_NOTICE, E_USER_WARNING ,E_USER_ERROR
o E_STRICT(„best practices“ notices)
o E_DEPRECATED (features that might disappear in future php versions)
o E_ALL(everything) o and some more
• Typical production setting: E_ALL & ~E_DEPRECATED & ~E_STRICT
Exception handling is used to change the normal flow of the code execution if a specified error (exceptional) condition occurs. This condition is called an exception.
Exceptions or errors (more on that see below) end code execution, unless they are handled with try-catch.
try { // code that throws an Exception } catch (Exception $ex) { // Exception is handled, code continues }
Several catch statements may be used to differentiate between several kinds of exceptions and errors.
try { // code that throws an Exception } catch (CustomExceptionClass $ex) { // custom Exception is handled } catch (Exception $ex) { // Exception is handled } catch (Error $err) { // Error is handled }
Several errors may be handled with the same code.
try { // code that throws an Exception } catch (Exception | CustomException $ex) { // custom Exception and Exception }
Optional finally block contains code that runs after the trycatch block, no matter whether an error was caught or not
This is what normally happens when an exception is triggered:
• Since php 7, many errors php reports now throw an error exception, not a fatal error as before.
• Subclasses of error exist for the specific type of error, such as parseerror or typeerror.
• To facilitate backwards compatibility, error is not derived from exception.
• Both error and exception implement the throwable interface