XCVI. Session Handling Functions
Introduction
Session support in PHP consists of a way to preserve certain
data across subsequent accesses. This enables you to build
more customized applications and increase the appeal of your
web site.
A visitor accessing your web site is assigned an unique
id, the so-called session id. This is either stored in a
cookie on the user side or is propagated in the URL.
The session support allows you to register arbitrary numbers
of variables to be preserved across requests. When a visitor
accesses your site, PHP will check automatically (if session.auto_start
is set to 1) or on your request (explicitly through session_start()
or implicitly through session_register()) whether a specific
session id has been sent with the request. If this is the
case, the prior saved environment is recreated.
Caution
If you do turn on session.auto_start then you cannot put
objects into your sessions since the class definition has
to be loaded before starting the session in order to recreate
the objects in your session.
All registered variables are serialized after the request
finishes. Registered variables which are undefined are marked
as being not defined. On subsequent accesses, these are
not defined by the session module unless the user defines
them later.
Note: Session handling was added in PHP 4.0.
Note: Please note when working with sessions that a record
of a session is not created until a variable has been registered
using the session_register() function or by adding a new
key to the $_SESSION superglobal array. This holds true
regardless of if a session has been started using the session_start()
function.
Sessions and security
External links: Session fixation
The session module cannot guarantee that the information
you store in a session is only viewed by the user who created
the session. You need to take additional measures to actively
protect the integrity of the session, depending on the value
associated with it.
Assess the importance of the data carried by your sessions
and deploy additional protections -- this usually comes
at a price, reduced convenience for the user. For example,
if you want to protect users from simple social engineering
tactics, you need to enable session.use_only_cookies. In
that case, cookies must be enabled unconditionally on the
user side, or sessions will not work.
There are several ways to leak an existing session id to
third parties. A leaked session id enables the third party
to access all resources which are associated with a specific
id. First, URLs carrying session ids. If you link to an
external site, the URL including the session id might be
stored in the external site's referrer logs. Second, a more
active attacker might listen to your network traffic. If
it is not encrypted, session ids will flow in plain text
over the network. The solution here is to implement SSL
on your server and make it mandatory for users.
Requirements
No external libraries are needed to build this extension.
Note: Optionally you can use shared memory allocation (mm),
developed by Ralf S. Engelschall, for session storage. You
have to download mm and install it. This option is not available
for Windows platforms. Note that the session storage module
for mm does not guarantee that concurrent accesses to the
same session are properly locked. It might be more appropriate
to use a shared memory based filesystem (such as tmpfs on
Solaris/Linux, or /dev/md on BSD) to store sessions in files,
because they are properly locked.
