Monday, 20th June 2005
PHP globals on a web hosting server
Today i uploaded my site to the server of my new hosting company (nexcess.net). My intention of independence from databases finally payed off. All i needed to do was ftp the entire website development directory on my disk (local copy) to the server and voila everything worked like a charm. Not database setup, scripts to run, configuration to perform etc. Deployment is a developer's nightmare (actually bugbear is more apt to describe it). In this case, deploying my site was like being in developer nirvana.
The core functionality of the site worked perfectly, with no clitches. Always pleasing when the first demo works. A situation that Joel described was thankfully avoided. However there was a minor glitch in the feedback and guestbook pages which needed a fix. These were the only pages with user input. Below is a description of the problem.
PHP provides a large number of predefined variables to any script which it runs. Many of these variables, however, are dependent upon which server is running, the version and setup of the server, and other factors. PHP allows you to access form variables using either of the following syntax.
$_POST['var_name'] or $_GET['var_name']$var_name
There exists another option to access the form variables which is $_REQUEST['var_name']. But it is advised against using it. I'll explain why shortly.
In PHP 4 and later, the default value for the PHP directive register_globals is off. This is a major change in PHP. Having register_globals off affects the set of predefined variables available in the global scope. For example, to get DOCUMENT_ROOT you'll use $_SERVER['DOCUMENT_ROOT'] instead of $DOCUMENT_ROOT, or $_GET['id'] from the URL http://www.example.com/test.php?id=3 instead of $id, or $_ENV['HOME'] instead of $HOME. Once again this illustrates how depending on a server configuration (especially in a scenario such as shared web hosting) is asking for trouble. Probably now it might be more clear why my design goals included maximum independence from server specific configuration and ease of deployment.
Coming to our form example, we should always use option 1 as opposed to option 2 since Global variables defaults to off on most servers these days. Now my local server (XAMPP) had register_globals ON and my scripts had used option 1. Now all of a sudden my code to validate { if ( ! IsSet($var_name)) } was failing, since the variables were in undefined state owing to the configuration switch.
Thankfully i googled and hunted the fix quickly enough. As i was looking for solutions, i stumbled across this useful piece of information about security risk of Registering the Globals. Read about it here.
A shared server means you are generally stuck with the setting they provide you with and are limited with the number of configuration changes you can make. However If the host (hosting company) allows per-directory overrides (for example, .htaccess files), you can control the configuration directives. For instance to achive the register globals effect if the server hasnt enabled it for you in default, then the following might help. I haven't experimented with this yet though.
"You can toggle whatever your host has for this directive by simply adding an .htaccess file to your php code directories with a single line to turn the register_globals on/off: php_flag register_globals off ".
< Directory /whatever/ >AllowOverride Options
< /Directory >Most (all) shared hosting companies aren't going to allow access to their httpd.conf file so any host worth their salt had better at least allow override directives, which means they would already have this directive entry for you when you initially pay them and setup your account.
Posted by Nikhil on Monday, 20th June 2005 in TechnoBabble