Database Reference
In-Depth Information
opportunity to update the information as necessary. Cookies are easy to use, but it's
possible for the client to modify cookie contents, possibly tricking the application into
misbehaving. Other client-side session storage techniques suffer the same drawback.
The alternative to client-side storage is to maintain session state on the server side.
Information about client activity is stored somewhere on the server, such as in a file, in
shared memory, or in a database. The only information maintained on the client side
is a unique identifier that the server generates and sends to the client when the session
begins. The client sends this value to the server with each subsequent request so the
server can associate the client with the appropriate session. Common techniques for
tracking the session ID are to store it in a cookie or to encode it in request URLs (useful
for clients that have cookies disabled). The server gets the ID from the cookie value or
by extracting it from the URL.
Server-side session storage is more secure than storing information on the client because
the application maintains control over the session contents. The only value present on
the client side is the session ID, so the client can't modify session data unless the appli‐
cation permits it. It's still possible for a client to tinker with the ID and send back a
different one, but if IDs are unique and selected from a very large pool of possible values,
a malicious client is unlikely to guess the ID of another valid session. If you are concerned
about other clients stealing valid session IDs by network snooping, use sessions within
the context of secure connections (for example, by using SSL). But that is beyond the
scope of this topic.
Server-side methods for managing sessions commonly store session contents in per‐
sistent backing storage such as a file or a database. Database storage characteristics differ
from file storage, such as that you eliminate the filesystem clutter that results from
having many session files, and you can use the same MySQL server to handle session
traffic for multiple web servers. If this appeals to you, the techniques shown in the
chapter enable you to integrate MySQL-based session management into your applica‐
tions. The chapter shows how to implement server-side database-backed session man‐
agement for several of our API languages:
• The Perl Apache::Session module includes most of the capabilities needed for ses‐
sion management. It can store session information in files or in any of several da‐
tabase systems, including MySQL, PostgreSQL, and Oracle.
• The Ruby
CGI::Session
class provides session-handling capability. It uses tempo‐
rary files by default, but permits other storage managers to be used, such as the
mysql-session
package for MySQL.
• PHP includes native session support. The implementation uses temporary files by
default, but applications can supply their own handler routines for session storage.
This makes it possible to plug in a storage module that uses MySQL.
