Chapter 14.  Session Handling

14. Session Handling

IN CHAPTER 13, "USER AUTHENTICATION AND SESSION Security," we discussed authenticating user sessions. In addition to being able to determine that a sequence of requests are simply coming from the same user, you very often want to maintain state information for a user between requests. Some applications, such as shopping carts and games, require state in order to function at all, but these are just a subset of the expanse of applications that use state.

Handling state in an application can be a challenge, largely due to the mass of data it is possible to accumulate. If I have a shopping cart application, I need for users to be able to put objects into the cart and track the status of that cart throughout their entire session. PHP offers no data persistence between requests, so you need to tuck this data away someplace where you can access it after the current request is complete.

There are a number of ways to track state. You can use cookies, query string munging, DBM-based session caches, RDBMS-backed caches, application serverbased caches, PHP's internal session tools, or something developed in house. With this daunting array of possible choices, you need a strategy for categorizing your techniques. You can bifurcate session-management techniques into two categories, depending on whether you store the bulk of the data client side or server side:

• Client-side sessions Client-side sessions encompass techniques that require all or most of the session-state data to be passed between the client and server on every request. Client-side sessions may seem rather low-tech, and they are sometimes called heavyweight in reference to the amount of client/server data transmission required. Heavyweight sessions excel where the amount of state data that needs to be maintained is small. They require little to no back-end support. (They have no backing store.) Although they are heavyweight in terms of content transmitted, they are very database/back-end efficient. This also means that they fit with little modification into a distributed system.

• Server-side sessions Server-side sessions are techniques that involve little client/server data transfer. These techniques typically involve assigning an ID to a session and then simply transmitting that ID. On the server side, state is managed in some sort of session cache (typically in a database or file-based handler), and the session ID is used to associate a particular request with its set of state information. Some server-side session techniques do not extend easily to run in a distributed architecture.

We have looked at many session-caching mechanisms in the previous chapters, caching various portions of a client's session to mete out performance gains. The principal difference between session caching as we have seen it before and session state is that session caching takes data that is already available in a slow fashion and makes it available in a faster, more convenient, format. Session state is information that is not available in any other format. You need the session state for an application to perform correctly.