Session handling functionsSessions
&reftitle.intro;
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.
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.
Session handling was added in PHP 4.0.
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
addditional 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.
&reftitle.required;
&no.requirement;
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 appropiate 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.
&reference.session.configure;
&reference.session.ini;
&reftitle.resources;
&no.resource;
&reference.session.constants;
&reftitle.examples;
As of PHP 4.1.0, $_SESSION is available as a
global variable just like $_POST,
$_GET, $_REQUEST and so on.
Unlike $HTTP_SESSION_VARS,
$_SESSION is always global. Therefore, you do not
need to use the global
keyword for $_SESSION. Please note that this
documentation has been changed to use
$_SESSION everywhere. You can substitute
$HTTP_SESSION_VARS for
$_SESSION, if you prefer the former. Also note
that you must start your session using session_start
before use of $_SESSION becomes available.
The keys in the $_SESSION associative
array are subject to the
same limitations as regular variable names in PHP, i.e. they cannot
start with a number and must start with a letter or underscore.
For more details see the section on
variables in this manual.
If register_globals
is disabled, only members of the global associative array
$_SESSION can be registered as session
variables. The restored session variables will only be available
in the array $_SESSION.
Use of $_SESSION (or
$HTTP_SESSION_VARS with PHP 4.0.6 or less) is
recommended for improved security and code readablity. With
$_SESSION, there is no need to use the
session_register,
session_unregister,
session_is_registered functions. Session variables
are accessible like any other variables.
Registering a variable with $_SESSION.
]]>
Unregistering a variable with $_SESSION and
register_globals disabled.
]]>
Unregistering a variable with register_globals
enabled, after registering it using
$_SESSION.
]]>
If register_globals
is enabled, then each global variable can be registered as session
variable. Upon a restart of a session, these variables will be restored
to corresponding global variables. Since PHP must know which global
variables are registered as session variables, users need to register
variables with session_register function.
You can avoid this by simply setting entries in
$_SESSION.
If you are using $_SESSION and disable register_globals,
do not use session_register,
session_is_registered and
session_unregister, if your scripts shall work
in PHP 4.2 and earlier. You can use these functions in 4.3 and later.
If you enable register_globals,
session_unregister should be used since
session variables are registered as global variables when
session data is deserialized. Disabling register_globals
is recommended for both security and performance reasons.
Registering a variable with register_globals
enabled
]]>
If register_globals
is enabled, then the global variables and the
$_SESSION entries will automatically reference the
same values which were registered in the prior session instance.
There is a defect in PHP 4.2.3 and earlier. If you register a new
session variable by using session_register, the
entry in the global scope and the $_SESSION entry will
not reference the same value until the next
session_start. I.e. a modification to the newly
registered global variable will not be reflected by the
$_SESSION entry. This has been corrected in PHP 4.3.
Passing the Session ID
There are two methods to propagate a session id:
Cookies
URL parameter
The session module supports both methods. Cookies are optimal, but
because they are not always available, we also provide an alternative
way. The second method embeds the session id directly into URLs.
PHP is capable of transforming links transparently. Unless you are using
PHP 4.2 or later, you need to enable it manually when building PHP.
Under UNIX, pass
--enable-trans-sid to configure. If this build
option and the run-time option
session.use_trans_sid are enabled, relative
URIs will be changed to contain the session id automatically.
The arg_separator.output
&php.ini; directive allows to customize the argument seperator. For full
XHTML conformance, specify & there.
Alternatively, you can use the constant SID which is
always defined. If the client did not send an appropriate session
cookie, it has the form session_name=session_id.
Otherwise, it expands to an empty string. Thus, you can embed it
unconditionally into URLs.
The following example demonstrates how to register a variable, and
how to link correctly to another page using SID.
Counting the number of hits of a single user
Hello visitor, you have seen this page times.
The strip_tags is used when printing the SID
in order to prevent XSS related attacks.
Printing the SID, like shown above, is not necessary if
--enable-trans-sid was used to compile PHP.
Non-relative URLs are assumed to point to external sites and
hence don't append the SID, as it would be a security risk to
leak the SID to a different server.
Custom Session Handlers
To implement database storage, or any other storage method, you
will need to use session_set_save_handler to
create a set of user-level storage functions.
&reference.session.functions;