A session manages the interaction between a web browser and a web server. For example, a session allows an application to track the items in a shopping cart, the status of a customer account application process, whether or not a user is logged in, or the finalizing of an order. Sessions are essential to most web database applications.
A session has two components: session variables and a session identifier (ID). The session variables are the state information that's related to a user's interaction with an application. For example, the session variables might store that the user's shopping cart contains five items, what those items are, their price, what items the user has viewed, and that the user is logged into the application. The session variables are stored at the web server or database server, and are located using the session ID.
When a session is started, the user's browser is given a session ID. This ID is then included with subsequent requests to the server. When a browser makes a request, the server uses the session ID to locate the corresponding session variables, and the variables are read or written as required. In practice, session variables are typically stored at the web server in a file (the PHP default) or at the database server in a table. Figure 10-1 shows how the session variables for Beth's session are identified and stored in the web server environment; the session ID distinguishes between Beth's session and other users of the system.
Using sessions, all of the variables that represent the state of an application don't need to be transmitted over the Web. The session ID is transmitted between the browser and server with each HTTP request and response, but the session data itself is stored at the server. The session ID is therefore like the ticket given at a cloakroom. The ticket is much easier to carry around and ensures that you get back your own hat and coat. Storing variables at the server also helps prevent accidental or intentional tampering with state information.
The session ID is usually transmitted as a cookie . A cookie is a named piece of text that is stored in a web browser, and is sent with HTTP requests, like data sent with the GET or POST methods. You can find out more about cookies from the interesting Cookie Central web site at http://www.cookiecentral.com/faq/ or more formally in RFC 2109 at http://ietf.org/rfc/rfc2109.txt?number=2109.
When you manage session variables at the web server, they need to be stored for each browser session. But for how long should the session variables be stored? Because HTTP is stateless, there is no way to know when a user has finished with a session. Ideally, the user logs out of an application by requesting a logout script that explicitly ends the session. However, because a server can never be sure if a user is still there, the server needs to clean up old sessions that have not been used for a period of time. Unused sessions consume resources on the server and present a security risk. How long the timeout should be depends on the needs of the application, and we discuss this in more detail later in this chapter.
In summary, there are three characteristics of session management over the Web:
Information or state must be stored. Information that must be maintained across multiple HTTP requests is stored in session variables.
Each HTTP request must carry an identifier that allows the server to process the request with the correct session variables.
Sessions need to have a timeout. Otherwise, if a user leaves the web site, there is no way the server can tell when the session should end.