This session is about best practices and awareness to server specific programming and how to avoid it. How to write code that will run on any server with any configuration – things like file functions, directories, locale issues, EGPCS; Maybe even design patterns to help do that.
2. What's the point?
• Save time
• on deployment
• on upgrades
• on switching servers
• on configuration changes
• Avoid frustration
• Professionalism
2| Sep 17, 2008 |
6. Directives
PHP has many directives which enable different
configurations
Most directives will be in your php.ini, though on some
distros extensions' directives are separated to different
files
Never assume a
directive's value!
* in the following slides values in []
are recommended values for development
6| Sep 17, 2008 |
7. Directives (cont)
There are four ways to mark a PHP script
The following directives may be different on different
machines
• short_open_tag [off]
• asp_tags [off]
Always use full tags <?php ?> to make sure your
application runs on every machine
<?= is short tags!
7| Sep 17, 2008 |
8. Directives (cont)
PHP was created with some magic capabilities which may
be changed through directives, like
• register_globals [off]
• magic_quotes_gpc [off]
Assuming these are set to On is not only bad for
portability, but may also be a security risk
8| Sep 17, 2008 |
9. Directives (cont)
Errors are a fact of life, so you should handle them
Never assume the server is taking care of them for you
• display_errors [on]
• error_reporting [E_ALL | E_STRICT]
9| Sep 17, 2008 |
10. Directives (cont)
A few more directives that should be noted
• max_execution_time
• upload_max_filesize
• include_path
10 | Sep 17, 2008 |
11. Directives (cont)
What can you do?
• Use a strict php.ini file in production (based on php.ini-
recommended)
• Check values of important php directives in runtime
• Change PHP_INI_ALL or PHP_INI_USER directives in runtime to
fit your needs
PHP_INI_USER Entry can be set in user scripts or in Windows registry
PHP_INI_PERDIR Entry can be set in php.ini, .htaccess or httpd.conf
PHP_INI_SYSTEM Entry can be set in php.ini or httpd.conf
PHP_INI_ALL Entry can be set anywhere
11 | Sep 17, 2008 |
12. Core Functions
PHP functions may behave differently on different
machines
• Some may not work at all
• Some may work strangely
Which functions should we look for?
• locale & time related functions [e.g. setlocale()]
• file system related functions [e.g. chmod(), is_link()]
• execution functions [e.g. proc_open(), shell_exec()]
12 | Sep 17, 2008 |
14. The Good Functions
PHP has a few functions which may help us
• sys_get_temp_dir()
• tempnam()
14 | Sep 17, 2008 |
15. Extensions' Functions
API functions of PHP extensions may be missing
If you need to use an extension – check that it is there
• function_exists()
• extension_loaded()
15 | Sep 17, 2008 |
16. Disabled Functions
Many shared hosting providers limit access to potentially
hazardous functions, such as shell execution functions
Disabling functions is done through disable_functions and
disable_classes directives
If a function is disabled, function_exists() on that
function name will return false
16 | Sep 17, 2008 |
17. Contexts
A context class is a factory class which does the required
action or returns the required class based on the relevant
context
By wrapping server specific functions in a context class,
you can normalize the behavior of these functions to
match any server
17 | Sep 17, 2008 |
18. Contexts (cont)
class Context_Os {
/**
* Execute a command
* @param string $command
* @return boolean
*/
public function static exec($command) {
if (DIRECTORY_SEPARATOR === '') {
return Executer_Windows::exec($command);
} else {
return Executer_Linux::exec($command);
}
}
}
18 | Sep 17, 2008 |
19. Frameworks
Frameworks are good practice to limit the risk
Never trust them until you know you can trust them
They are not a bullet-proof solution to the problem
19 | Sep 17, 2008 |
20. Bootstrapping
• Use a different bootstrap file for development and for
production
• Set all the directives you may during runtime in that
bootstrap to limit the risk
• Check all the mandatory extensions you need are there
• Check for potentially missing functions which are vital
for your application
20 | Sep 17, 2008 |
21. Deployment Script
If you don't wish to check for server integrity on each
request in your bootstrap file, keep an integrity check
script which does the heavier checks
It won't save you from server changes or upgrades, unless
you run it again
21 | Sep 17, 2008 |
22. Conclusions
• Get used to using constants
• Check and set important
directives
• Check for crucially needed
extensions and functions
• Use a bootstrap file or a
deployment script
• Be paranoid
22 | Sep 17, 2008 |
23. Questions?
Now would be a great time to fill
in your evaluation forms :-)
23 Sep 17, 2008 |
|