mirror of
https://github.com/macintoshplus/doc-en.git
synced 2026-03-29 20:32:07 +02:00
91e836093c
as UNIX is a registered trademark by the Open Group. References to UNIX were left in where it made sense, like example outputs, and so forth. You can read the Trademark User Guide for "UNIX" at: http://www.unix.org/tmug2.ps or http://www.unix.org/tmug2.pdf git-svn-id: https://svn.php.net/repository/phpdoc/en/trunk@147067 c90b9560-bf6c-de11-be94-00142212c4b1
420 lines
15 KiB
XML
420 lines
15 KiB
XML
<?xml version="1.0" encoding="iso-8859-1"?>
|
|
<!-- $Revision: 1.41 $ -->
|
|
<reference id="ref.session">
|
|
<title>Session handling functions</title>
|
|
<titleabbrev>Sessions</titleabbrev>
|
|
|
|
<partintro>
|
|
|
|
<section id="session.intro">
|
|
&reftitle.intro;
|
|
<para>
|
|
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.
|
|
</para>
|
|
<para>
|
|
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.
|
|
</para>
|
|
<para>
|
|
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 <link
|
|
linkend="ini.session.auto-start">session.auto_start</link>
|
|
is set to 1) or on your request (explicitly through
|
|
<function>session_start</function> or implicitly through
|
|
<function>session_register</function>) whether a specific session
|
|
id has been sent with the request. If this is the case, the prior
|
|
saved environment is recreated.
|
|
</para>
|
|
<caution>
|
|
<para>
|
|
If you do turn on <link linkend="ini.session.auto-start">
|
|
session.auto_start</link> 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.
|
|
</para>
|
|
</caution>
|
|
<para>
|
|
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.
|
|
</para>
|
|
<note>
|
|
<para>
|
|
Session handling was added in PHP 4.0.
|
|
</para>
|
|
</note>
|
|
<note>
|
|
<para>
|
|
Please note when working with sessions that a record of a session
|
|
is not created until a variable has been registered using the
|
|
<function>session_register</function> function or by adding a new
|
|
key to the <varname>$_SESSION</varname> superglobal array. This
|
|
holds true regardless of if a session has been started using the
|
|
<function>session_start</function> function.
|
|
</para>
|
|
</note>
|
|
</section>
|
|
|
|
<section id="session.security">
|
|
<title>Sessions and security</title>
|
|
<para>
|
|
External links: <ulink url="&url.session-fixation;">Session fixation</ulink>
|
|
</para>
|
|
<para>
|
|
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.
|
|
</para>
|
|
<para>
|
|
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
|
|
<literal>session.use_only_cookies</literal>. In that case,
|
|
cookies must be enabled unconditionally on the user side, or
|
|
sessions will not work.
|
|
</para>
|
|
<para>
|
|
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.
|
|
</para>
|
|
</section>
|
|
<section id="session.requirements">
|
|
&reftitle.required;
|
|
&no.requirement;
|
|
<note>
|
|
<para>
|
|
Optionally you can use shared memory allocation (mm), developed by
|
|
Ralf S. Engelschall, for session storage. You have to download
|
|
<ulink url="&url.mm;">mm</ulink> 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.
|
|
</para>
|
|
</note>
|
|
</section>
|
|
|
|
&reference.session.configure;
|
|
|
|
&reference.session.ini;
|
|
|
|
<section id="session.resources">
|
|
&reftitle.resources;
|
|
&no.resource;
|
|
</section>
|
|
|
|
&reference.session.constants;
|
|
|
|
<section id="session.examples">
|
|
&reftitle.examples;
|
|
<note>
|
|
<para>
|
|
As of PHP 4.1.0, <varname>$_SESSION</varname> is available as a
|
|
global variable just like <varname>$_POST</varname>,
|
|
<varname>$_GET</varname>, <varname>$_REQUEST</varname> and so on.
|
|
Unlike <varname>$HTTP_SESSION_VARS</varname>,
|
|
<varname>$_SESSION</varname> is always global. Therefore, you do not
|
|
need to use the <link
|
|
linkend="language.variables.scope"><command>global</command></link>
|
|
keyword for <varname>$_SESSION</varname>. Please note that this
|
|
documentation has been changed to use
|
|
<varname>$_SESSION</varname> everywhere. You can substitute
|
|
<varname>$HTTP_SESSION_VARS</varname> for
|
|
<varname>$_SESSION</varname>, if you prefer the former. Also note
|
|
that you must start your session using <function>session_start</function>
|
|
before use of <varname>$_SESSION</varname> becomes available.
|
|
</para>
|
|
<para>
|
|
The keys in the <varname>$_SESSION</varname> 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
|
|
<link linkend='language.variables'>variables</link> in this manual.
|
|
</para>
|
|
</note>
|
|
|
|
<para>
|
|
If <link
|
|
linkend="ini.register-globals">register_globals</link>
|
|
is disabled, only members of the global associative array
|
|
<varname>$_SESSION</varname> can be registered as session
|
|
variables. The restored session variables will only be available
|
|
in the array <varname>$_SESSION</varname>.
|
|
</para>
|
|
<para>
|
|
Use of <varname>$_SESSION</varname> (or
|
|
<varname>$HTTP_SESSION_VARS</varname> with PHP 4.0.6 or less) is
|
|
recommended for improved security and code readability. With
|
|
<varname>$_SESSION</varname>, there is no need to use the
|
|
<function>session_register</function>,
|
|
<function>session_unregister</function>,
|
|
<function>session_is_registered</function> functions. Session variables
|
|
are accessible like any other variables.
|
|
<example>
|
|
<title>
|
|
Registering a variable with <varname>$_SESSION</varname>.
|
|
</title>
|
|
<programlisting role="php">
|
|
<![CDATA[
|
|
<?php
|
|
session_start();
|
|
// Use $HTTP_SESSION_VARS with PHP 4.0.6 or less
|
|
if (!isset($_SESSION['count'])) {
|
|
$_SESSION['count'] = 0;
|
|
} else {
|
|
$_SESSION['count']++;
|
|
}
|
|
?>
|
|
]]>
|
|
</programlisting>
|
|
</example>
|
|
<example>
|
|
<title>
|
|
Unregistering a variable with <varname>$_SESSION</varname> and
|
|
<link
|
|
linkend="ini.register-globals">register_globals</link> disabled.
|
|
</title>
|
|
<programlisting role="php">
|
|
<![CDATA[
|
|
<?php
|
|
session_start();
|
|
// Use $HTTP_SESSION_VARS with PHP 4.0.6 or less
|
|
unset($_SESSION['count']);
|
|
?>
|
|
]]>
|
|
</programlisting>
|
|
</example>
|
|
</para>
|
|
<para>
|
|
<caution>
|
|
<para>
|
|
Do NOT unset the whole <varname>$_SESSION</varname> with
|
|
<literal>unset($_SESSION)</literal> as this will disable the
|
|
registering of session variables through the
|
|
<varname>$_SESSION</varname> superglobal.
|
|
</para>
|
|
</caution>
|
|
</para>
|
|
<para>
|
|
<example>
|
|
<title>
|
|
Unregistering a variable with <link
|
|
linkend="ini.register-globals">register_globals</link>
|
|
enabled, after registering it using
|
|
<varname>$_SESSION</varname>.
|
|
</title>
|
|
<programlisting role="php">
|
|
<![CDATA[
|
|
<?php
|
|
session_start();
|
|
// With PHP 4.3 and later, you can also simply use the prior example.
|
|
session_unregister('count');
|
|
?>
|
|
]]>
|
|
</programlisting>
|
|
</example>
|
|
</para>
|
|
<para>
|
|
If <link
|
|
linkend="ini.register-globals">register_globals</link>
|
|
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 <function>session_register</function> function.
|
|
You can avoid this by simply setting entries in
|
|
<varname>$_SESSION</varname>.
|
|
<caution>
|
|
<para>
|
|
If you are using <varname>$_SESSION</varname> and disable <link
|
|
linkend="ini.register-globals">register_globals</link>,
|
|
do not use <function>session_register</function>,
|
|
<function>session_is_registered</function> and
|
|
<function>session_unregister</function>, if your scripts shall work
|
|
in PHP 4.2 and earlier. You can use these functions in 4.3 and later.
|
|
</para>
|
|
<para>
|
|
If you enable <link
|
|
linkend="ini.register-globals">register_globals</link>,
|
|
<function>session_unregister</function> should be used since
|
|
session variables are registered as global variables when
|
|
session data is deserialized. Disabling <link
|
|
linkend="ini.register-globals">register_globals</link>
|
|
is recommended for both security and performance reasons.
|
|
</para>
|
|
</caution>
|
|
<example>
|
|
<title>
|
|
Registering a variable with <link
|
|
linkend="ini.register-globals">register_globals</link>
|
|
enabled
|
|
</title>
|
|
<programlisting role="php">
|
|
<![CDATA[
|
|
<?php
|
|
if (! isset($_SESSION['count'])) {
|
|
$_SESSION['count'] = 1;
|
|
} else {
|
|
$_SESSION['count']++;
|
|
}
|
|
?>
|
|
]]>
|
|
</programlisting>
|
|
</example>
|
|
</para>
|
|
<para>
|
|
If <link
|
|
linkend="ini.register-globals">register_globals</link>
|
|
is enabled, then the global variables and the
|
|
<varname>$_SESSION</varname> entries will automatically reference the
|
|
same values which were registered in the prior session instance.
|
|
</para>
|
|
<para>
|
|
There is a defect in PHP 4.2.3 and earlier. If you register a new
|
|
session variable by using <function>session_register</function>, the
|
|
entry in the global scope and the <varname>$_SESSION</varname> entry will
|
|
not reference the same value until the next
|
|
<function>session_start</function>. I.e. a modification to the newly
|
|
registered global variable will not be reflected by the
|
|
<varname>$_SESSION</varname> entry. This has been corrected in PHP 4.3.
|
|
</para>
|
|
</section>
|
|
|
|
<section id="session.idpassing">
|
|
<title>Passing the Session ID</title>
|
|
<para>
|
|
There are two methods to propagate a session id:
|
|
<itemizedlist>
|
|
<listitem>
|
|
<simpara>
|
|
Cookies
|
|
</simpara>
|
|
</listitem>
|
|
<listitem>
|
|
<simpara>
|
|
URL parameter
|
|
</simpara>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
<para>
|
|
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.
|
|
</para>
|
|
<para>
|
|
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 <link linkend="install.configure.enable-trans-sid">
|
|
--enable-trans-sid</link> to configure. If this build
|
|
option and the run-time option
|
|
<literal>session.use_trans_sid</literal> are enabled, relative
|
|
URIs will be changed to contain the session id automatically.
|
|
<note>
|
|
<para>
|
|
The <link linkend="ini.arg-separator.output">arg_separator.output</link>
|
|
&php.ini; directive allows to customize the argument seperator. For full
|
|
XHTML conformance, specify &amp; there.
|
|
</para>
|
|
</note>
|
|
</para>
|
|
<para>
|
|
Alternatively, you can use the constant <literal>SID</literal> which is
|
|
always defined. If the client did not send an appropriate session
|
|
cookie, it has the form <literal>session_name=session_id</literal>.
|
|
Otherwise, it expands to an empty string. Thus, you can embed it
|
|
unconditionally into URLs.
|
|
</para>
|
|
<para>
|
|
The following example demonstrates how to register a variable, and
|
|
how to link correctly to another page using SID.
|
|
<example>
|
|
<title>Counting the number of hits of a single user</title>
|
|
<programlisting role="php">
|
|
<![CDATA[
|
|
<?php
|
|
if (!session_is_registered('count')) {
|
|
session_register('count');
|
|
$count = 1;
|
|
} else {
|
|
$count++;
|
|
}
|
|
?>
|
|
|
|
Hello visitor, you have seen this page <?php echo $count; ?> times.<p>
|
|
|
|
To continue, <A HREF="nextpage.php?<?php echo strip_tags (SID)?>">click here</A>
|
|
]]>
|
|
</programlisting>
|
|
</example>
|
|
</para>
|
|
<para>
|
|
The <function>strip_tags</function> is used when printing the SID
|
|
in order to prevent XSS related attacks.
|
|
</para>
|
|
<para>
|
|
Printing the SID, like shown above, is not necessary if
|
|
<link linkend="install.configure.enable-trans-sid">
|
|
--enable-trans-sid</link> was used to compile PHP.
|
|
</para>
|
|
<note>
|
|
<para>
|
|
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.
|
|
</para>
|
|
</note>
|
|
</section>
|
|
|
|
<section id="session.customhandler">
|
|
<title>Custom Session Handlers</title>
|
|
<para>
|
|
To implement database storage, or any other storage method, you
|
|
will need to use <function>session_set_save_handler</function> to
|
|
create a set of user-level storage functions.
|
|
</para>
|
|
</section>
|
|
</partintro>
|
|
|
|
&reference.session.functions;
|
|
|
|
</reference>
|
|
|
|
<!-- Keep this comment at the end of the file
|
|
Local variables:
|
|
mode: sgml
|
|
sgml-omittag:t
|
|
sgml-shorttag:t
|
|
sgml-minimize-attributes:nil
|
|
sgml-always-quote-attributes:t
|
|
sgml-indent-step:1
|
|
sgml-indent-data:t
|
|
indent-tabs-mode:nil
|
|
sgml-parent-document:nil
|
|
sgml-default-dtd-file:"../../../manual.ced"
|
|
sgml-exposed-tags:nil
|
|
sgml-local-catalogs:nil
|
|
sgml-local-ecat-files:nil
|
|
End:
|
|
vim600: syn=xml fen fdm=syntax fdl=2 si
|
|
vim: et tw=78 syn=sgml
|
|
vi: ts=1 sw=1
|
|
-->
|
|
|