How Users Connect to Our Application | Core Web Application Development with PHP and MySQL

As we discussed in Chapter 13, "Web Applications and the Internet," HTTP is a stateless protocol, meaning that no information is remembered between connections to the web server. Clients connect, request information, and then receive it or an error message. Then the connection closes. The web server remembers little about the connection except what it feels is necessary for logging and resumes waiting for requests from other clients (see Figure 15-1). While this simplicity is what has made it such a successful protocol on the Internet, it has also shown itself to have limitations.

Figure 15-1. HTTP as a stateless protocol.

Obviously, there are times when we want to "follow" users around our site or application. This could be to remember choices they have made on previous pages and tailor what we show them based on this, or to let users log in so that we might show them information that is specific to them. Without any specific functionality to do this, we could use parameters in the URI to remember as much information as possible between pages.

If we had a small web application that let users customize the color and font with which the page was displayed, we might write the following:

 <html> <head>   <title> Please Choose the Type of Music You Want</title> </head> <body bgcolor='<?php echo $_GET['back_color'] ?>'> <?php   $out_url = 'music_choice.php';   $out_url .= "?back_color={$_GET['back_color']}";   $out_url .= "&fore_color={$_GET['fore_color']}";   $out_url .= "&font_face={$_GET['font_face'']}";   $out_url .= "&font_size={$_GET['font_size']}"; ?>   <form action='<?php echo $out_url ?>' method='POST'>     <font face='<?php echo $_GET['font_face'] ?>'           size='<?php echo $_GET['font_size'] ?>'           color='<?php echo $_GET['fore_color'] ?>'>     Please Choose your Type Of Music:     <option name='music' value='classical'>Classical<br/>     <option name='music' value='rock'>Rock<br/>     <option name='music' value='techno'>Techno<br/>     <option name='music' value='jazz'>Jazz<br/>     <input type='submit' value='Submit'/>     </font>   </form> </html>

Even for this simple example, we are burdening our URI with lots of extra baggage and spending processing time setting it up for every page. When we want to store even more information for the client, our URIs become unwieldy.

If we were clever, we could use our database server to store all this information instead and send an identifier for the user that would identify the record in the database with the user's information. For example, we could reduce the excess baggage on our URI to a single parameter called uid to get the customized information for the page, as follows:

 <?php   $uid = intval($_GET['uid']);   // go to database and get information for this user, put   // values into $user_info array.   $user_info = get_user_info_from_db($uid);   $out_url = "music_choice.php?uid=$uid"; ?> <html> <head>   <title> Please Choose the Type of Music You Want</title> </head> <body bgcolor='<?php echo $user_info['back_color'] ?>'>   <form action='<?php echo $out_url ?>' method='POST'>     <font face='<?php echo $user_info['font_face'] ?>'           size='<?php echo $user_info['font_size'] ?>'           color='<?php echo $user_info['fore_color'] ?>'>     Please Choose your Type Of Music:     <option name='music' value='classical'>Classical<br/>     <option name='music' value='rock'>Rock<br/>     <option name='music' value='techno'>Techno<br/>     <option name='music' value='jazz'>Jazz<br/>     <input type='submit' value='Submit'/>     </font>   </form> </html>

This solution works, meaning that we generate less cumbersome URIs, but it has some serious flaws:

We now have to add code to process the uid parameter and get the information we may or may not need for the uid on top of every page.
This is extremely insecure. Client browsers will store this uid in their history cache, and anybody who sees this can use it to learn about the given user.
We have no effective way of knowing when a user is "done" with his information, so we have to leave it in the database for some time and add code later on to periodically clean up any entries in this database that should be considered "expired."

Fortunately, HTTP 1.1 introduced a new feature called cookie, an innovation that came out of the browser work at Netscape Corporation in the mid-1990s. A cookie is a small token of information specific to a particular site or page. When a web server sends a response to a request, it sends one or more cookies along with it. The server can include in this cookie pieces of information and means of identifying them. When the client browser later makes a request of the same server, it sends any cookies it received previously from that server along with the request.

Using these cookies, a number of web programming environments have developed a feature called sessions. This is a way of using cookies to remember a particular user and send that information back to the client with responses. It solves most of the shortcomings we mentioned in our database/parameter scheme and reduces most of the tedious work to a few function calls, although security always remains a concern. (See Chapter 16, "Securing Your Web Applications: Planning and Code Security.")

With sessions and cookies, we finally have a way to follow or track users as they visit our application. We will use this as the basis for much of the user authentication we do. We will cover the full usage of both cookies and sessions in Chapter 19, "Cookies and Sessions." For the rest of this chapter, we will look at strategies for managing and tracking users, including how we might store their information.