[MANUAL] English:

[zend.git] / documentation / manual / ru / module_specs / Zend_Session-GlobalSessionManagement.xml

<sect1 id="zend.session.globalsessionmanagement">

    <title>Общее управление сессиями<!--Global Session Management--></title>

    <para>
        Поведение сессий, принятое по умолчанию, можно изменить, используя
        статические методы класса Zend_Session. Все управление производится
        посредством Zend_Session, включая конфигурирование
        <ulink url="http://www.php.net/session#session.configuration">через
        опции, предоставляемые расширением ext/session</ulink>, с использованием
        метода <code>Zend_Session::setOptions()</code>.
<!--
        The default behavior of sessions can be modified using the static methods in Zend_Session. All management and
        manipulation of global session management occurs using Zend_Session, including configuration of the
        <ulink url="http://www.php.net/session#session.configuration">usual options provided by ext/session</ulink>
        , using <code>Zend_Session::setOptions()</code>. For example, failure to insure the use of a safe save_path or a
        unique cookie name by ext/session using <code>Zend_Session::setOptions()</code> may result in security issues.
-->
    </para>

    <sect2 id="zend.session.setoptions">

        <title>Zend_Session::setOptions()</title>

        <para>
            Когда запрашивается первое пространство имен, то автоматически
            запустится Zend_Session, если только оно не было запущено ранее
            через метод
            <link linkend="zend.session.startingasession"><code>Zend_Session::start()</code></link>.
            Встроенный в PHP механизм сессий будет использовать принятые по
            умолчанию настройки из Zend_Session, пока они не будут изменены
            через метод <code>Zend_Session::setOptions()</code>.
<!--
            When the first session namespace is requested, Zend_Session will autostart itself, unless already started
            explicitly by using
            <link linkend="zend.session.startingasession"><code>Zend_Session::start()</code>
            </link>
            . The underlying PHP session will use defaults from Zend_Session, unless modified first by
            <code>Zend_Session::setOptions()</code>.
-->
        </para>

        <para>
            Для того, чтобы передать опции, просто передайте базовое имя (без
            приставки <code>session.</code>) как часть массива методу
            <code>Zend_Session::setOptions()</code>. Если опции не были
            установлены, то Zend_Session будет сначала использовать
            рекомендуемые опции, затем установки по умолчанию из php.ini.
            Предложения по оптимизации работы с опциями отправляйте в список
            рассылки
            <ulink url="mailto:fw-auth@lists.zend.com">fw-auth@lists.zend.com</ulink>.
<!--
            To pass the options just pass the basename (the non <code>session.</code> part) as part of an array to
            <code>Zend_Session::setOptions()</code>. Without setting any options, Zend_Session will utilize the
            recommended options first, then the default php.ini settings. Community feedback about best practices for
            these options should be sent to
            <ulink url="mailto:fw-auth@lists.zend.com">fw-auth@lists.zend.com</ulink>
            .
-->
        </para>

        <para>
            "Автоматическое" конфигурипрование этой компоненты с использованием
            Zend_Config_Ini:
<!--
            To "automatically" configure this component using an ".ini" file with Zend_Config_Ini:
-->
            <example>
                <title>Использование Zend_Config для конфирурирования Zend_Session<!--Using Zend_Config to Configure Zend_Session--></title>
<programlisting language="php"><![CDATA[<?php
$config = new Zend_Config_Ini('myapp.ini', 'sandbox');
require_once 'Zend/Session.php';
Zend_Session::setOptions($config->toArray());
?>]]></programlisting>
            </example>
            Используемый файл "myapp.ini":
<!--
            The corresponding "myapp.ini" file:
-->
            <example>
                <title>myapp.ini</title>
<programlisting language="php">
<![CDATA[
;  Настройки по умолчанию для производственного сервера
[live]
; bug_compat_42
; bug_compat_warn
; cache_expire
; cache_limiter
; cookie_domain
; cookie_lifetime
; cookie_path
; cookie_secure
; entropy_file
; entropy_length
; gc_divisor
; gc_maxlifetime
; gc_probability
; hash_bits_per_character
; hash_function
; имя должно быть уникальным для всех приложений, использующих
; одно и то же доменное имя
name = UNIQUE_NAME
; referer_check
; save_handler
; save_path
; serialize_handler
; use_cookies
; use_only_cookies
; use_trans_sid

; remember_me_seconds = <integer seconds>
; strict = on|off

; Наш тестовый сервер использует те же настройки, что и наш
; производственный сервер за исклочением тех, что переопределяются ниже:
[sandbox : live]
; Не забудьте создать эту директорию и сделать ее доступной для чтения
; и записи через PHP
save_path = /home/myaccount/zend_sessions/myapp
use_only_cookies = on
; Когда индентификатор сессии сохраняется в куках, запрашивать TTL
; через 10 дней
remember_me_seconds = 864000
]]></programlisting>
            </example>
        </para>

    </sect2>

    <sect2 id="zend.session.options">

        <title>Опции<!--Options--></title>

        <para>
            Большинство опций, указанных ниже, не нуждается в дополнительных
            комментариях сверх того, что написано в стандартной документации по
            PHP.
<!--
            Most options shown above need no explanation beyond that found in the standard PHP documentation.
-->
            <itemizedlist mark='opencircle'>
                <listitem>
                    <para>
                        boolean <code>strict</code> - отключает автоматический
                        запуск <code>Zend_Session</code> при использовании
                        <code>new Zend_Session_Namespace()</code>.
<!--
                        boolean <code>strict</code> - disables automatic starting of <code>Zend_Session</code> when
                        using <code>new Zend_Session_Namespace()</code>.
-->
                    </para>
                </listitem>
                <listitem>
                    <para>
                        integer <code>remember_me_seconds</code> - время
                        хранения идентификатора сессии в куках после того, как
                        агент пользователя завершит свою работу (т.е. когда окно
                        броузера будет закрыто).
<!--
                        integer <code>remember_me_seconds</code> - how long should session id cookie persist, after user
                        agent has ended (i.e. browser window closed)
-->
                    </para>
                </listitem>
                <listitem>
                    <para>
                        string <code>save_path</code> - корректное значение
                        зависит от системы и должно указываться разработчиком с
                        использованием <emphasis>абсолютного
                        пути</emphasis> к директории, доступной для чтения и
                        записи процессом PHP. Если директория на заданном пути
                        не существует или недоступна, то
                        <code>Zend_Session</code> бросает исключение во время
                        старта (т.е. когда вызывается метод
                        <code>start()</code>)
<!--
                        string <code>save_path</code> - The correct value is system dependent, and should be provided by
                        the developer using an <emphasis>absolute path</emphasis> to a directory readable
                        and writable by the PHP process.  If a writable path is not supplied, then <code>Zend_Session
                        </code> will throw an exception when started (i.e. when <code>start()</code> is called).
-->
                    </para>
                    <note>
                        <title>Угроза безопасности<!--Security Risk--></title>
                        <para>
                            Если путь доступен для чтения другими приложениями,
                            то возможен угон сессий (session hijacking). Если
                            путь доступен для записи другими приложениями, то
                            возможно заражение сессий
                            (<ulink url="http://en.wikipedia.org/wiki/Session_poisoning">session poisoning</ulink>).
                            Если этот путь используется совместно с другими
                            пользователями или с другими PHP-приложениями, то
                            это создает различные угрозы безопасности,
                            включая кражу содержимого сессий, угон сессий и
                            коллизии при "сборке мусора" (например, работа
                            приложения другого пользователя может вызвать
                            удаление файлов сессий вашего приложения).
<!--
                            If the path is readable by other applications, then session hijacking might be possible. If
                            the path is writable by other applications, then
                            <ulink url="http://en.wikipedia.org/wiki/Session_poisoning">session poisoning</ulink>
                            might be possible. If this path is shared with other users or other PHP applications,
                            various security issues might occur, including theft of session content, hijacking of
                            sessions, and collision of garbage collection (e.g. another user's application might cause
                            PHP to delete your application's session files).
-->
                        </para>
                        <para>
                            Например, атакующий может зайти на сайт жертвы для
                            получения сессионных куков. Затем он изменяет путь
                            куков на собственный домен для того же сервера и
                            заходит на собственный сайт для выполнения
                            <code>var_dump($_SESSION)</code>. Вооруженный
                            информацией о том, как жертва использует данные в
                            своих сессиях, атакующий может модифицировать данные
                            сессии (заражение сессии), возвращает значение пути
                            куков на исходный (ведущий на сайт жертвы) и делает
                            запросы с сайта жертвы, используя зараженную сессию.
                            Даже если оба приложения на том же сервере не имеют
                            прав чтения/записи в директории save_path другого
                            приложения, то в том случае, если можно заходить в
                            директорию save_path и атакующий имеет контроль над
                            одним из сайтов, он может изменить save_path своего
                            сайта на save_path жертвы и таким образом выполнить
                            заражение сессии под некоторыми общими
                            конфигурациями PHP. Поэтому значение save_path не
                            должно быть достоянием общественности и должно быть
                            изменено на секретное значение, уникальное для
                            каждого приложения.
<!--
                            For example, an attacker can visit the victim's website to obtain a session cookie. Then
                            edit the cookie path to his own domain on the same server, before visiting his own website
                            to execute <code>var_dump($_SESSION)</code>. Armed with detailed knowledge of the victim's
                            use of data in their sessions, the attacker can then modify the session state (poisoning the
                            session), alter the cookie path back to the victim's website, and then make requests from
                            the victim's website using the poisoned session. Even if two applications on the same server
                            do not have read/write access to the other application's save_path, if the save_path is
                            guessable, and the attacker has control over one of these two websites, the attacker could
                            alter their website's save_path to use the other's save_path, and thus accomplish session
                            poisoning, under some common configurations of PHP. Thus, the value for save_path should not
                            be made public knowledge, and should be altered to a secure location unique to each
                            application.
-->
                        </para>
                    </note>
                </listitem>
                <listitem>
                    <para>
                        string <code>name</code> - корректное значение зависит
                        от системы и должно устанавливаться разработчиком, с
                        использованием короткого значения,
                        <emphasis>уникального</emphasis> для
                        приложения ZF.
<!--
                        string <code>name</code> - The correct value is system dependent, and should be provided by
                        the developer using a short value <emphasis>unique</emphasis> to the ZF
                        application.
-->
                    </para>
                    <note>
                        <title>Угроза безопасности<!--Security Risk--></title>
                        <para>
                            Если настройки в <code>php.ini</code> для
                            <code>session.name</code> одинаковые для
                            приложений (например, "PHPSESSID" для настроек по
                            умолчанию) и через одно доменное имя доступны два и
                            более приложений (например,
                            <code>http://www.somewebhost.com/~youraccount/index.php</code>),
                            то они будут использовать одни и те же данные
                            сессий для посетителей, посещающих оба сайта. Это
                            может привести к разрушению данных сессий.
<!--
                            If the <code>php.ini</code> setting for <code>session.name</code>
                            is the same (e.g. the default "PHPSESSID"), and there are two or more PHP applications
                            accessible through the same domain name (e.g.
                            <code>http://www.somewebhost.com/~youraccount/index.php</code>), then they will share
                            the same session data for website visitors that visit both websites.  Additionally,
                            possible corruption of session data may result.
-->
                        </para>
                    </note>
                </listitem>
                <listitem>
                    <para>
                        boolean <code>use_only_cookies</code> - во избежание
                        появления дополнительных угроз безопасности не изменяйте
                        значение, принятое по умолчанию для этой опции, на
                        другое.
<!--
                        boolean <code>use_only_cookies</code> - In order to avoid introducing additional security risks,
                        do not alter the default value of this option.
-->
                        <note>
                            <title>Угроза безопасности<!--Security Risk--></title>
                            <para>
                                Если эта опция не включена, то аттакующий может
                                легко "фиксировать" идентификаторы сессии,
                                используя ссылки на атакуемый сайт вида
                                <code>http://www.victim-website.com/index.php?PHPSESSID=fixed_session_id</code>.
                                Фиксация будет работать, если жертва не всегда
                                имеет куки с идентификатором сессии для
                                victim-website.com. Как только жертва будет
                                использовать известный атакующему идентификатор
                                сессии, атакующий может попытаться угнать
                                сессию, имитируя реального пользователя и
                                эмулируя агента жертвы.
<!--
                                If this setting is not enabled, an attacker can easily fix victim's session ids, using
                                links on the attacker's website, such as
                                <code>http://www.victim-website.com/index.php?PHPSESSID=fixed_session_id</code>. The
                                fixation works, if the victim does not already have a session id cookie for
                                victim-website.com. Once a victim is using a known session id, the attacker can then
                                attempt to hijack the session by pretending to be the victim, and emulating the victim's
                                user agent.
-->
                            </para>
                        </note>
                    </para>
                </listitem>
            </itemizedlist>
        </para>

    </sect2>

    <sect2 id="zend.session.regenerateid">

        <title>regenerateId()</title>

        <sect3 id="zend.session.regenerateid.intro">

            <title>Введение: идентификаторы сессий<!--Introduction: Session Identifiers--></title>

            <para>
                Введение: Наилучшей практикой в использовании сессий с ZF будет
                использование куков вместо сохранения идентификатора сессии в
                URL для отслеживания отдельных пользователей. По
                умолчанию эта компонента использует только куки для хранения
                идентификатора сессии. Значением, сохраняемым в куках, является
                уникальный идентификатор сессии. Расширение ext/session
                использует этот идентификатор для поддержки однозначно
                определяемой связи "один-к-одному" между посетителем сайта и
                хранилищем постоянных данных сессии, уникальным для каждого
                посетителя. Zend_Session* является оберткой к этому механизму
                хранения (<varname>$_SESSION</varname>) с объектно-ориентированным
                интерфейсом. К сожалению, если атакующий получил доступ к
                идентификатору сессии в куках, то он может угнать сессию
                посетителя. Эта проблема не является присущей только PHP или
                Zend Framework. Метод <code>regenerateId()</code> позволяет
                приложению изменять идентификатор сессии (сохраненный в куках
                посетителя) на новое случайное значение. Замечание: Несморя на
                то, что эти термины не равнозначны, для удобочитаемости мы будем
                попеременно использовать "агент пользователя" и "веб-броузер".
<!--
                Introduction: Best practice in relation to using sessions with ZF calls for using a browser cookie (i.e.
                a normal cookie stored in your web browser), instead of embedding a unique session identifier in URLs as
                a means to track individual users. By default this component uses only cookies to maintain session
                identifiers. The cookie's value is the unique identifier of your browser's session. PHP's ext/session
                uses this identifier to maintain a unique one-to-one relationship between website visitors, and
                persistent session data storage unique to each visitor. Zend_Session* wraps this storage mechanism
                (<varname>$_SESSION</varname>) with an object-oriented interface. Unfortunately, if an attacker gains access
                to the value of the cookie (the session id), an attacker might be able to hijack a visitor's session.
                This problem is not unique to PHP, or Zend Framework. The <code>regenerateId()</code> method allows
                an application to change the session id (stored in the visitor's cookie) to a new, random, unpredictable
                value. Note: Although not the same, to make this section easier to read, we use the terms "user agent"
                and "web browser" interchangeably.
-->
            </para>

            <para>
                Почему?: Если атакующий получил валидный идентификатор сессии,
                то он может имитировать реального пользователя (жертву) и затем
                получить доступ к конфиденциальной информации или манипулировать
                данными жертвы через ваше приложение. Изменение идентификатора
                сессии помогает защитить пользователя от угона сессии. Если
                идентификатор сессии был изменен и атакующий не знает его новое
                значение, то он не может использовать новый идентификатор сессии
                в своей попытке угона сессии посетителя. Даже если атакующий
                получил доступ к старому идентификатору сессии, то
                <code>regenerateId()</code> перемещает данные сессии со старого
                идентификатора на новый, и поэтому данные этой сессии не будут
                доступны через старый идентификатор.
<!--
                Why?: If an attacker obtains a valid session identifier, an attacker might be able to impersonate a
                valid user (the victim), and then obtain access to confidential information or otherwise manipulate the
                victim's data managed by your application. Changing session ids helps protect against session hijacking.
                If the session id is changed, and an attacker does not know the new value, the attacker can not use the
                new session id in their attempts to hijack the visitor's session. Even if an attacker gains access to an
                old session id, <code>regenerateId()</code> also moves the session data from the old session id "handle"
                to the new one, so no data remains accessible via the old session id.
-->
            </para>

            <para>
                Когда использовать regenerateId(): Добавление
                <code>Zend_Session::regenerateId()</code> в файл загрузки
                Zend Framework является одним из самых безопасных и надежных
                способов регенерации идентификаторов сессии в куках агента
                пользователя. Само по себе отсутствие условной логики,
                определяющей, когда регенерировать идентификатор сессии, не
                является признаком плохо разработанного кода. Но, несмотря на
                то, что регенерация при каждом запросе пересекает некоторые
                возможные пути атак, не все хотят мириться с небольшой потерей в
                производительности и пропускной способности, связанными с
                регенерацией. Поэтому приложения обычно пытаются определить
                ситуации, связанные с наибольшим риском, и только тогда
                регенерируют идентификаторы сессий. В случаях, когда привилегии
                сессии посетителя сайта "обостряются" (например, посетитель
                заново проходит аутентификацию до изменения его личного
                "профиля") или когда производятся "чувствительные" для
                безопасности изменения параметров сессии, используется
                <code>regenerateId()</code> для регенерации идентификатора
                сессии. Если вы вызываете функцию <code>rememberMe()</code>, то
                не используйте <code>regenerateId()</code>, т.к. первая функция
                вызывает вторую. Если пользователь успешно залогинился на вашем
                сайте, используйте <code>rememberMe()</code> вместо
                <code>regenerateId()</code>.
<!--
                When to use regenerateId(): Adding <code>Zend_Session::regenerateId()</code> to your Zend Framework
                bootstrap yields one of the safest and most secure ways to regenerate session id's in user agent
                cookies. If there is no conditional logic to determine when to regenerate the session id, then there are
                no flaws in that logic. Although regenerating on every request prevents several possible avenues of
                attack, not everyone wants the associated small performance and bandwidth cost. Thus, applications
                commonly try to dynamically determine situations of greater risk, and only regenerate the session ids in
                those situations. Whenever a website visitor's session's privileges are "escalated" (e.g. a visitor
                re-authenticates their identity before editing their personal "profile"), or whenever a security
                "sensitive" session parameter change occurs, consider using <code>regenerateId()</code> to create a new
                session id. If you call the <code>rememberMe()</code> function, then don't use
                <code>regenerateId()</code>, since the former calls the latter. If a user has successfully logged into
                your website, use <code>rememberMe()</code> instead of <code>regenerateId()</code>.
-->
            </para>

        </sect3>

        <sect3 id="zend.session.regenerateid.details">

            <title>Угон и фиксация сессии<!--Session Hijacking and Fixation--></title>

            <para>
                Отсутствие XSS-уязвимостей на сайте помогает предотвратить угон
                сессий c него. Согласно
                статистике <ulink url="http://secunia.com/">Secunia</ulink>,
                <ulink url="http://en.wikipedia.org/wiki/Cross_site_scripting">
                XSS (межсайтовый скриптинг)</ulink> - довольно распространенное
                явление. Лучше минимизировать возможный ущерб от XSS, следуя
                наилучшей практике программирования, чем предполагать, что этого
                никогда не случится с вами. Атакующему, использующему
                XSS, не нужно иметь прямой доступ к сетевому трафику жертвы.
                Если жертва уже имеет сессионные куки, то XSS с внедрением кода
                Javascript позволит атакующему прочитать куки и украсть сессию.
                Если жертва не имеет сессионные куки, то, используя XSS с
                внедрением кода Javascript, атакующий может создать куку с
                заранее известным идентификатором сессии в броузере жертвы,
                затем установить идентичную куку в своей системе, чтобы угнать
                сессию жертвы. Если жертва посетит сайт атакующего, то
                атакующий может также сэмулировать и другие доступные для
                идентификации характеристики агента пользователя жертвы. Если
                ваш сайт имеет XSS-уязвимости, то атакующий может внедрить
                AJAX-код, который скрытно "заходит" на сайт атакующего, и
                атакующий может узнать характеристики броузера жертвы и о
                скомпрометированной сессии на сайте жертвы. Но несмотря на все
                это, атакующий не может изменить данные сессии на стороне
                сервера при условии, что разработчик корректно установил
                значение опции <code>save_path</code>.
<!--
                Avoiding
                <ulink url="http://en.wikipedia.org/wiki/Cross_site_scripting">cross-site script (XSS) vulnerabilities</ulink>
                helps preventing session hijacking. According to
                <ulink url="http://secunia.com/">Secunia's statistics</ulink>
                XSS problems occur frequently, regardless of the languages used to create web applications. Rather than
                expecting to never have a XSS problem with an application, plan for it by following best practices to
                plan for it by following best practices to help minimize damage, if it occurs. With XSS, an attacker
                does not need direct access to a victim's network traffic. If the victim already has a session cookie,
                Javascript XSS might allow an attacker to read the cookie and steal the session. For victims with no
                session cookies, using XSS to inject Javascript, an attacker could create a session id cookie on the
                victim's browser with a known value, then set an identical cookie on the attacker's system, in order to
                hijack the victim's session. If the victim visited an attacker's website, then the attacker can also
                emulate most other identifiable characteristics of the victim's user agent. If your website has an XSS
                vulnerability, the attacker might be able to insert an AJAX Javascript that secretly "visits" the
                attacker's website, so that the attacker knows the victim's browser characteristics and becomes aware of
                a compromised session at the victim website. However, the attacker can not arbitrarily alter the
                server-side state of PHP sessions, provided the developer has correctly set the value for the
                <code>save_path</code> option.
-->
            </para>

            <para>
                Сам по себе вызов <code>Zend_Session::regenerateId()</code>
                в то время, как сессия еще только начинает использоваться, не
                предотвращает атаку через фиксацию сессии, за исключением
                того случая, когда вы можете отличить сессию, созданную
                атакующим, имитирующим личность жертвы. На первый взгляд это
                противоречит предыдущему утверждению, но до тех пор, пока мы не
                будем считать атакующим того, кто первый иницировал создание
                настоящей сессии на вашем сайте. Сессия сначала используется
                атакующим, который знает результат инициализации
                (<code>regenerateId()</code>). Атакующий затем использует новый
                идентификатор сессии вместе с найденной XSS-уязвимостью или
                добавляет идентификатор сессии в ссылку на сайт атакующего
                (работает в том случае, если
                <code>use_only_cookies = off</code>).
<!--
                By itself, calling <code>Zend_Session::regenerateId()</code> when the user's session is first used,
                does not prevent session fixation attacks, unless you can distinguish between a session originated by an
                attacker emulating the victim. At first, this might sound contradictory to previous statement above,
                until we consider an attacker who first initiates a real session on your website. The session is "first
                used" by the attacker, who then knows the result of the initialization (<code>regenerateId()</code>).
                The attacker then uses the new session id in combination with an XSS vulnerability, or injects the
                session id via a link on the attacker's website (works if <code>use_only_cookies = off</code>).
-->
            </para>

            <para>
                Если вы можете различать атакующего и жертву, использующих один
                и тот же идентификатор сессии, то это может решить проблему
                увода сессии. Тем не менее, такое распознавание обычно
                принуждает к поиску компромисса с юзабилити, т.к. методы
                различения нередко являются неточными. Для примера, если запрос
                получен с IP в стране, отличающейся от IP запроса, при котором
                была создана сессия, то это может означать, что новый запрос
                производится уже атакующим. При выполнении следующих условий
                приложение сайта не сможет различить жертву и атакующего:
<!--
                If you can distinguish between an attacker and victim using the same session id, then session hijacking
                can be dealt with directly. However, such distinctions usually involve some form of usability tradeoffs,
                because the methods of distinction are often imprecise. For example, if a request is received from an IP
                in a different country than the IP of the request when the session was created, then the new request
                probably belongs to an attacker. Under the following conditions, there might not be any way for a
                website application to distinguish between a victim and an attacker:
-->
                <itemizedlist mark='opencircle'>
                    <listitem>
                        <para>
                            - атакующий первый иницировал сессию на вашем сайте для получения валидного идентификатора сессии
<!--
                            - attacker first initiates a session on your website to obtain a valid session id
-->
                        </para>
                    </listitem>
                    <listitem>
                        <para>
                            - атакующий использует XSS-уязвимость на вашем сайте для создания куки в броузере жертвы с валидным идентификатором сессии (т.е. фиксация сессии)
<!--
                            - attacker uses XSS vulnerability on your website to create a cookie on the victim's browser
                            with the same, valid session id (i.e. session fixation)
-->
                        </para>
                    </listitem>
                    <listitem>
                        <para>
                            - атакующий и его жертва заходят через одну и ту же группу прокси-серверов (например, оба находятся за одним и тем же файрволом в большой компании - такой, как AOL)
<!--
                            - both the victim and attacker originate from the same proxy farm (e.g. both are behind the
                            same firewall at a large company, like AOL)
-->
                        </para>
                    </listitem>
                </itemizedlist>

                Пример кода ниже намного затрудняет получение атакующим текущего идентификатора сессии жертвы, за исключением тех случаев, когда атакующий уже выполнил первые два шага из приведенных выше.
<!--
                The sample code below makes it much harder for an attacker to know the current victim's session id,
                unless the attacker has already performed the first two steps above.
-->
            </para>

            <example>
                <title>Анонимная сессия и фиксация сессии<!--Anonymous Sessions and Session Fixation--></title>
<programlisting language="php"><![CDATA[<?php
require_once 'Zend/Session.php';
$defaultNamespace = new Zend_Session_Namespace();

if (!isset($defaultNamespace->initialized))
{
    Zend_Session::regenerateId();
    $defaultNamespace->initialized = true;
}
?>]]></programlisting>
            </example>

        </sect3>

    </sect2>

    <sect2 id="zend.session.rememberme">

        <title>rememberMe(integer $seconds)</title>

        <para>
            Обычно сессия заканчивается, когда агент пользователя завершает
            сеанс работы - например, пользователь закрыл окно броузера. Тем не
            менее, после того как пользователь зашел в систему, может
            понадобиться хранить его сессию 24 часа и больше. Программное
            обеспечение форумов обычно предоставляет пользователю возможность
            выбирать, сколько времени должна храниться сессиия.  Используйте
            <code>Zend_Session::rememberMe()</code> для отправки
            обновленной сессионной куки агенту пользователя со временем жизни,
            по умолчанию равному <code>remember_me_seconds</code>, который равен
            2 неделям до тех пор, пока вы не измените это значение через метод
            <code>Zend_Session::setOptions()</code>. Для того, чтобы
            помешать угону или фиксации сессии, используйте эту функцию, когда
            пользователь успешно прошел аутентификацию и ваше приложение
            выполнило "регистрацию"
<!--
            Ordinarily, sessions end when the user agent ends its "session", such as when an end user closes their
            browser window. However, when a user logs in to your website, they might want their virtual session to last
            for 24 hours, or even longer. Forum software commonly gives the user a choice for how long their session
            should last. Use <code>Zend_Session::rememberMe()</code> to send an updated session cookie to the user
            agent with a lifetime defaulting to <code>remember_me_seconds</code>, which is set to 2 weeks, unless you
            modify that value using <code>Zend_Session::setOptions()</code>. To help thwart session fixation/hijacking, use this
            function when a user successfully authenticates and you application performs a "login".
-->
        </para>

    </sect2>

    <sect2 id="zend.session.forgetme">

        <title>forgetMe()</title>

        <para>
            Эта функция является дополнением к <code>rememberMe()</code>.
            Она возвращает сессионную куку к тому состоянию, при котором ее
            время жизни завершается в тот момент, когда агент пользователя
            завершает сеанс работы (например, пользователь закрыл окно своего
            броузера).
<!--
            This function complements <code>rememberMe()</code> by changing the session cookie back to a lifetime ending
            when the user agent ends its session (e.g. user closes their browser window).
-->
        </para>

    </sect2>

    <sect2 id="zend.session.sessionexists">

        <title>sessionExists()</title>

        <para>
            Используйте этот метод для определения того, есть ли уже сессия для
            текущего агента пользователя/запроса. Он может использоваться до
            старта сессии и независимо от всех других методов Zend_Session и
            Zend_Session_Namespace.
<!--
            Use this method to determine if a session already exists for the current user agent/request. It may be used
            before starting a session, and independently of all other Zend_Session and Zend_Session_Namespace methods.
-->
        </para>

    </sect2>

    <sect2 id="zend.session.destroy">

        <title>destroy(bool $remove_cookie = true, bool $readonly = true)</title>

        <para>
            <code>Zend_Session::destroy()</code> уничтожает все постоянные
            данные, связанные с текущей сессией. Это не влияет на переменные в
            PHP, поэтому ваши сессии с пространствами имен (экземпляры
            <code>Zend_Session_Namespace</code>) остаются доступными для чтения.
            Для выхода из системы установите необязательный параметр в
            <constant>TRUE</constant> (по умолчанию он равен <constant>TRUE</constant>), при
            этом будет удалена кука с идентификатором сессии в агенте
            пользователя. Установленный в <constant>TRUE</constant> необязательный
            параметр <varname>$readonly</varname> блокирует возможность записи в
            данные сессии (т.е. в $_SESSION) для экземпляров
            Zend_Session_Namespace и методов Zend_Session.
<!--
            <code>Zend_Session::destroy()</code> destroys all of the persistent data associated with the current
            session. However, no variables in PHP are affected, so your namespaced sessions (instances of
            <code>Zend_Session_Namespace</code>) remain readable. To complete a "logout", set the optional parameter to
            true (default is true) to also delete the user agent's session id cookie. The optinal <varname>$readonly</varname>
            parameter removes the ability for Zend_Session_Namespace instances, and Zend_Session methods to write to the
            session data store (i.e. $_SESSION).
-->
        </para>

        <note>
            <title>Исключения<!--Throws--></title>
            <para>
                По умолчанию <varname>$readonly</varname> установлен в
                <constant>TRUE</constant> и дальнейшие действия, подразумевающие запись
                в хранилище данных сессии, вызовут генерацию исключения.
<!--
                By default, <varname>$readonly</varname> is enabled and further actions involving writing to the session data
                store will throw an error.
-->
            </para>
        </note>

    </sect2>

    <sect2 id="zend.session.stop">

        <title>stop()</title>

        <para>
            Этот метод не делает ничего, кроме переключения флага в
            Zend_Session для предотвращения дальнейшей записи в хранилище
            данных сессии (т.е.<varname>$_SESSION</varname>). Одним из вариантов его
            использования является временное отключение возможности записи в
            хранилище данных сессии через экземпляры
            <code>Zend_Session_Namespace</code> или методы
            <code>Zend_Session</code> во время выполнения кода,
            связанного с отображением вида.
            Попытка выполнить действия, подразумевающие запись через эти
            экземпляры или методы вызовет генерацию исключения.
<!--
            This method does absolutely nothing more than toggle a flag in Zend_Session to prevent further writing to
            the session data store (i.e. <varname>$_SESSION</varname>). We are specifically requesting feedback on this
            feature. Potential uses/abuses might include temporarily disabling the use of
            <code>Zend_Session_Namespace</code> instances or <code>Zend_Session</code> methods to write to the session
            data store, while execution is transfered to view-related code. Attempts to perform actions involving writes
            via these instances or methods will throw an error.
-->
        </para>

    </sect2>

    <sect2 id="zend.session.writeClose">

        <title>writeClose($readonly = true)</title>

        <para>
            Закрывает сессию, завершает запись и отсоединяет $_SESSION от
            средства хранения на сервере. Это завершит внутреннее преобразование
            данных для данного запроса. Необязательный параметр булевого типа
            $readonly позволяет отключить возможность записи (т.е. генерация
            исключения при попытке записи через любые методы
            Zend_Session_Namespace или Zend_Session).
<!--
            Shutdown the session, close writing and detach $_SESSION from the back-end storage mechanism. This will
            complete the internal data transformation on this request. The optional $readonly boolean parameter can
            remove write access (i.e. throw error if any Zend_Session_Namespace or Zend_Session methods attempt writes).
-->
        </para>

        <note>
            <title>Исключения<!--Throws--></title>
            <para>
                По умолчанию <varname>$readonly</varname> включен и дальнейшие
                действия, подразумевающие запись в хранилище данных сессии,
                вызовут генерацию исключения.
<!--
                By default, <varname>$readonly</varname> is enabled and further actions involving writing to the session data
                store will throw an error. However, some legacy application might expect $_SESSION to remain writeable
                after ending the session via session_write_close(). Although not considered "best practice", the
                <varname>$readonly</varname> option is available for those who need it.
-->
            </para>
        </note>

    </sect2>

    <sect2 id="zend.session.expiresessioncookie">

        <title>expireSessionCookie()</title>

        <para>
            Этот метод отправляет куку с уже истекшим временем действия, что
            вызывает удаление сессионной куки в агенте пользователя. Иногда этот
            метод используется для выхода из системы со стороны клиента.
<!--
            This method sends an expired session id cookie, causing the client to delete the session cookie. Sometimes
            this technique is used to perform a client-side logout.
-->
        </para>

    </sect2>

    <sect2 id="zend.session.savehandler">

        <title>setSaveHandler(Zend_Session_SaveHandler_Interface $interface)</title>

        <para>
            Большинство разработчиков находят достаточным использовать принятый
            по умолчанию механизм хранения сессионных данных.
            Этот метод предоставляет объектно-ориентированную обертку для <code>
            <ulink url="http://php.net/session_set_save_handler">session_set_save_handler()</ulink>
            </code>.
<!--
            Most developers will find the default save handler sufficient. This method provides an object-oriented
            wrapper for <code>
            <ulink url="http://php.net/session_set_save_handler">session_set_save_handler()</ulink>
            </code>.
-->
        </para>

    </sect2>

    <sect2 id="zend.session.namespaceisset">

        <title>namespaceIsset($namespace)</title>

        <para>
            Используйте этот метод для определения того, существует ли
            пространство имен с данным именем или определенный индекс в данном
            пространстве имен.
<!--
            Use this method to determine if a session namespace exists, or if a particular index exists in a particular
            namespace.
-->
        </para>

        <note>
            <title>Исключения<!--Throws--></title>
            <para>
                Если Zend_Session не был помечен как доступный для чтения
                (например, до того, как Zend_Session был запущен), то будет
                сгенерировано исключение.
<!--
                An error will be thrown if Zend_Session is not marked as readable (e.g. before Zend_Session
                has been started).
-->
            </para>
        </note>

    </sect2>

    <sect2 id="zend.session.namespaceunset">

        <title>namespaceUnset($namespace)</title>

        <para>
            Вместо создания экземпляра Zend_Session_Namespace для пространства
            имен и итерации по его содержимому для удаления каждой отдельной
            записи используйте метод <code>namespaceUnset($namespace)</code> для
            быстрого удаления всего пространства имен и его содержимого. Как это
            справедливо для всех массивов в PHP, если переменная, содержащая
            массив, уничтожена, и этот массив содержал другие объекты, то эти
            объекты не уничтожаются, если они были сохранены по ссылке в других
            массивах/объектах. Это означает, что они остаются доступными через
            другие переменные. Поэтому <code>namespaceUnset()</code> не
            производит "глубокое" удаление содержимого записей в пространстве
            имен. За более подробной информацией обращайтесь к разделу
            <ulink url="http://php.net/references">References Explained</ulink>
            в документации по PHP.
<!--
            Instead of creating a Zend_Session instance for a namespace, and iterating over its contents to unset each
            entry, use <code>Zend_Session::namespaceUnset($namespace)</code> to efficiently unset (remove) an entire
            namespace and its contents. As with all arrays in PHP, if a variable containing an array is unset, and the
            array contains other objects, those objects will remain available, if they were also stored by reference in
            other array/objects that remain accessible via other variables. So <code>namespaceUnset()</code> does not
            perform a "deep" unsetting/deleting of the contents of the entries in the namespace. For a more detailed
            explanation, please see
            <ulink url="http://php.net/references">References Explained</ulink>
            in the PHP manual.
-->
        </para>

        <note>
            <title>Исключения<!--Throws--></title>
            <para>
                Если пространство имен недоступно для записи (например, после
                <code>destroy()</code>), то будет сгенерировано исключение.
<!--
                An error will be thrown if the namespace is not writable (e.g. after <code>destroy()</code>).
-->
            </para>
        </note>

    </sect2>

    <sect2 id="zend.session.namespaceget">

        <title>namespaceGet($namespace)</title>

        <para>
            Не рекомендуется к использованию: Используйте
            <code>getIterator()</code> в Zend_Session_Namespace. Этот метод
            возвращает массив содержимого пространства имен
            <varname>$namespace</varname>. Этот метод позднее может быть определен как
            закрытый. Если вы считаете, что есть разумные причины оставить этот
            метод открытым, то пишите в список рассылки
            <ulink url="mailto:fw-auth@lists.zend.com">fw-auth@lists.zend.com</ulink>.
            Участие в связанных темах также приветствуется :)
<!--
            DEPRECATED: Use <code>getIterator()</code> in Zend_Session_Namespace. This method returns an array of the
            contents of <varname>$namespace</varname>. If you have logical reasons to keep this method publicly accessible,
            please provide feedback to the
            <ulink url="mailto:fw-auth@lists.zend.com">fw-auth@lists.zend.com</ulink>
            mail list. Actually, all participation on any relevant topic is welcome :)
-->
        </para>

        <note>
            <title>Исключения<!--Throws--></title>
            <para>
                Если Zend_Session не был помечен как доступный для чтения
                (например, до того, как Zend_Session был запущен), то будет
                сгенерировано исключение.
<!--
                An error will be thrown if Zend_Session is not marked as readable (e.g. before Zend_Session
                has been started).
-->
            </para>
        </note>

    </sect2>

    <sect2 id="zend.session.getiterator">

        <title>getIterator()</title>

        <para>
            Используйте метод <code>getIterator()</code> для получения массива,
            содержащего имена всех пространств имен, и с которым можно
            производить итерации.
<!--
            Use <code>getIterator()</code> to obtain an iterable array containing the names of all namespaces.
-->
        </para>

        <example>
            <title>Уничтожение всех пространств имен<!--Unsetting All Namespaces--></title>
<programlisting language="php"><![CDATA[<?php
foreach(Zend_Session::getIterator() as $space) {
    try {
        $core->namespaceUnset($space);
    } catch (Zend_Session_Exception $e) {
        return; // possible if Zend_Session::stop() has been executed
    }
}

?>]]></programlisting>
        </example>

        <note>
            <title>Исключения<!--Throws--></title>
            <para>
                Если Zend_Session не был помечен как доступный для чтения
                (например, до того, как Zend_Session был запущен), то будет
                сгенерировано исключение.
<!--
                An error will be thrown if Zend_Session is not marked as readable (e.g. before Zend_Session
                has been started).
-->
            </para>
        </note>

    </sect2>

</sect1>