Session Management Over the Web - Page 3
April 24, 2002
Storing the state in the web server--the middle tier--can solve the problem
of increased request size and protect the state of an application from
accidental or intentional changes a user might make.
A session is a way to identify and manage the state--the
session variables--for a particular user. When a user sends an HTTP
request, the middle tier must process the current request in the context of
the user's session. When a session is started, the client is given a
session identifier--often a cookie--that is included with subsequent
requests to the server. The server uses the session identifier to locate the
corresponding session before processing the request.
Rather than storing all the variables needed to maintain state and include
them with each request, the browser stores a single session identifier that
finds and initializes the variables stored on the server. The session
identifier is like the ticket given at a cloak room. The ticket is much easier
to carry around and ensures that the holder gets her own hat and coat.
One implication of storing session variables in the middle tier is that
data needs to be stored for each session. The question is, for how long?
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, and the logout
script 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. This last point is important, because sessions
consume resources on the server, and dormant sessions may 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 session management over the Web
must exhibit:
- Information or state must be stored. For example, a selected
bottle of wine in a shopping cart, a customer name, or a credit card number
must be maintained across multiple HTTP requests.
- Each HTTP request must carry an identifier that allows the
server to process the request in the context of the stored state. For
example, when an order is submitted, it must be processed with the correct
items and customer details.
- 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.
PHP Session Management
With the release of PHP4, session management was introduced as an extension
to the PHP language. PHP provides several session-related functions, and
developing applications that use PHP sessions is straightforward. The three
important features of session management are mostly taken care of by the PHP
scripting engine.
In this section, we present how to use PHP sessions, showing how sessions
are started and ended and how session variables are used. We list the PHP
functions for building session-based web applications. Because not all
browsers support cookies, and some users actively disable them, we describe
how to use PHP sessions without relying on cookies. Finally, we show how to
configure PHP session management with a discussion on the garbage collection
used to remove old sessions and other configuration parameters.
Overview
An overview of PHP session management is shown in Figure
8-1. When a user first enters the session-based application by making a
request to a page that starts a session, PHP generates a session ID and
creates a file that stores the session-related variables. PHP sets a cookie to
hold the session ID in the response the script generates. The browser then
records the cookie and includes it in subsequent requests. In the example
shown in Figure
8-1, the script welcome.php records session variables in the
session store, and a request to next.php then has access to those
variables because of the session ID.
Figure 8-1. The interaction between the
browser and the server when initial requests are made to a session-based
application
|
|
The out-of-the-box configuration of PHP session management uses disk-based
files to store session variables. Using files as the session store is adequate
for most applications in which the numbers of concurrent sessions are limited.
A more scalable solution that uses a MySQL database as a session store is
provided in Appendix D.
Starting a Session
PHP provides a session_start( ) function that creates a new
session and subsequently identifies and establishes an existing one. Either
way, a call to the session_start( ) function initializes
a session.
Set-Cookie header field is included in the response. The response
sets up a session cookie in the browser with the name PHPSESSID
and the value of the session identifier. The PHP session management
automatically includes the cookie without the need to call to the
setcookie( ) or header( ) functions.
The session identifier (ID) is a random string of 32 hexadecimal digits,
such as fcc17f071bca9bf7f85ca281094390b4. As with other cookies,
the value of the session ID is made available to PHP scripts in the
$HTTP_COOKIE_VARS associative array and in the
$PHPSESSID variable.
When a new session is started, PHP creates a session file. With the default
configuration, session files are written in the /tmp directory using
the session identifier, prefixed with sess_, for the filename. The
filename associated with our example session ID is
/tmp/sess_fcc17f071bca9bf7f85ca281094390b4.
If a call is made to session_start( ), and the request
contains the PHPSESSID cookie, PHP attempts to find the session
file and initialize the associated session variables as discussed in the next
section. However, if the identified session file can't be found,
session_start( ) creates an empty session file.
Building Applications That Keep State - Page 2
Web Database Applications with PHP & MySQL
Session Management Over the Web (Cont.) - Page 4
|
