Page 272 - Beginning PHP 5.3

Part III: Using PHP in Practice
How It Works
As you can see, the process of capturing and displaying the submitted form data is really quite simple.
Because the form is sent using the post method, the script extracts the form field values from the
$_POST superglobal array, and displays each field value using echo():

<dt>First name</dt><dd><?php echo $_POST[“firstName”]?></dd>
<dt>Last name</dt><dd><?php echo $_POST[“lastName”]?></dd>
<dt>Password</dt><dd><?php echo $_POST[“password1”]?></dd>
<dt>Retyped password</dt><dd><?php echo $_POST[“password2”]?></dd>
<dt>Gender</dt><dd><?php echo $_POST[“gender”]?></dd>
<dt>Favorite widget</dt><dd><?php echo $_POST[“favoriteWidget”]?></dd>
<dt>Do you want to receive our newsletter?</dt><dd><?php echo
$_POST[“newsletter”]?></dd>
<dt>Comments</dt><dd><?php echo $_POST[“comments”]?></dd>
By the way, because the $_REQUEST superglobal contains the elements of both $_GET and $_POST, you
could instead access the form field values using $_REQUEST:
<dt>First name</dt><dd><?php echo $_REQUEST[“firstName”]?></dd>
Generally speaking, if you know that your user data will come from a form with a get or a post
method, it’s best to use $_GET or $_POST rather than $_REQUEST. This reduces ambiguity and the
chance of bugs appearing in your code, and also eliminates any risk of clashes between form fields
and cookies; for example, there might be a cookie with the same name as one of your form fields.

Dealing Securely with Form Data

Although the preceding script is just an example and is not designed for use in the real world, a couple
of security issues with the script are worth pointing out. First of all, you wouldn ’ t of course display the
password that the users had just entered (although you might send them their password in an email to
remind them of it).

Secondly, it ’ s generally a bad idea to pass any user - entered data — such as the values in $_GET and
$_POST — straight through to a statement like echo() or print() for displaying in a Web page. You

should never trust user input on a public Web site; a malicious user might be trying to break into the site.
It ’ s quite easy for a wrong - doer to submit form data to an unprotected site that could be used to gain
access to other users ’ credentials, for example. Therefore you should always validate (that is, check) or
filter user input to make sure it ’ s safe before you display it in a Web page. You find out more about this
topic in Chapter 20 .

Handling Empty Form Fields

The process_registration.php script assumes that the user has filled in all the fields in the form.
However, users often forget to (or don ’ t want to) fill in certain fields in a form. When this happens, some

234

9/21/09 7:23:37 PM
c09.indd 234
c09.indd 234 9/21/09 7:23:37 PM