repo_zf1/documentation/manual/ja/module_specs/Zend_Session-GlobalSessionManagement.xml

<?xml version="1.0" encoding="UTF-8"?>
<!-- Reviewed: no -->
<!-- EN-Revision: 24249 -->
<sect1 id="zend.session.global_session_management">

    <title>グローバルセッションの管理</title>

    <para>
        セッションのデフォルトの挙動を変更するには、<classname>Zend_Session</classname>
        の静的メソッドを使用します。グローバルセッションの管理や操作には、すべて
        <classname>Zend_Session</classname> を使用します。たとえば
        <ulink url="http://www.php.net/session#session.configuration">
        ext/session のオプション</ulink>
        を設定するには、<methodname>Zend_Session::setOptions()</methodname> を使用します。
        また、安全な <code>save_path</code> を使わなかったり ext/session
        で一意なクッキー名を使用しなかったりすると、
        <methodname>Zend_Session::setOptions()</methodname> はセキュリティの問題を引き起こします。
    </para>

    <sect2 id="zend.session.global_session_management.configuration_options">

        <title>設定オプション</title>

        <para>
            セッション名前空間が要求されると、事前に
            <link linkend="zend.session.advanced_usage.starting_a_session"><methodname>Zend_Session::start()</methodname></link>
            で開始されていない場合には <classname>Zend_Session</classname> が自動的にセッションを開始します。
            もととなる PHP セッションの設定は <classname>Zend_Session</classname>
            のデフォルトを使用します。これを変更するには、事前に
            <methodname>Zend_Session::setOptions()</methodname>
            を使用して設定しておきます。
        </para>

        <para>
            オプションを指定するには、そのベース名 ("<code>session.</code>" の後に続く部分)
            を <methodname>Zend_Session::setOptions()</methodname> に渡す配列のキーとします。
            配列の値が、そのセッションオプションの値として用いられます。
            何もオプションを設定しなければ、<classname>Zend_Session</classname> はまずデフォルトオプションを使用し、
            それがなければ php.ini の設定を使用します。
            これらのオプションの扱いについてのよい案があれば、ぜひ
            <ulink url="mailto:fw-auth@lists.zend.com">fw-auth@lists.zend.com</ulink>
            で教えてください。
        </para>

        <example id="zend.session.global_session_management.setoptions.example">

            <title>Zend_Config による Zend_Session の設定</title>

            <para>
                このコンポーネントを
                <link linkend="zend.config.adapters.ini"><classname>Zend_Config_Ini</classname></link>
                で設定するには、まず設定オプションを <acronym>INI</acronym> ファイルに追加します。
            </para>

            <programlisting language="ini"><![CDATA[
; 本番サーバのデフォルト設定
[production]
; 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 は、同じドメインを共有する PHP アプリケーション間で一意でなければなりません
name = UNIQUE_NAME
; referer_check
; save_handler
; save_path
; serialize_handler
; use_cookies
; use_only_cookies
; use_trans_sid

; remember_me_seconds = <整数の秒数>
; strict = on|off

; テスト環境の設定は本番サーバとほぼ同じです。設定が異なる部分だけを
; 以下で上書きします
[development : production]
; このディレクトリを事前に作成し、PHP スクリプトから rwx (読み書き可能)
; にしておくことを忘れないようにしましょう
save_path = /home/myaccount/zend_sessions/myapp
use_only_cookies = on
; セッション ID クッキーを持続させる場合は、その有効期限を 10 日にします
remember_me_seconds = 864000
]]></programlisting>

            <para>
                次に、この設定ファイルを読み込んで、その内容を配列として
                <methodname>Zend_Session::setOptions()</methodname> に渡します。
            </para>

            <programlisting language="php"><![CDATA[
$config = new Zend_Config_Ini('myapp.ini', 'development');

Zend_Session::setOptions($config->toArray());
]]></programlisting>

        </example>

        <para>
            上の例であげたほとんどのオプションについては、
            PHP のドキュメントで説明されているので、ここでの説明は不要でしょう。
            しかし、いくつか重要なものについては説明しておきます。
            <itemizedlist mark='opencircle'>
                <listitem>
                    <para>
                        boolean <code>strict</code> -
                        <code>new Zend_Session_Namespace()</code> を使用する際に、
                        <classname>Zend_Session</classname> が自動的に開始しないようにします。
                    </para>
                </listitem>
                <listitem>
                    <para>
                        integer <code>remember_me_seconds</code> -
                        ユーザエージェントが終了した (たとえば、ブラウザが終了した)
                        あと、どれだけの期間セッション ID クッキーを持続させるか。
                    </para>
                </listitem>
                <listitem>
                    <para>
                        string <code>save_path</code> -
                        正確な値はシステムに依存し、開発者がそのディレクトリまでの
                        <emphasis>絶対パス</emphasis> を指定する必要があります。
                        このディレクトリは、PHP のプロセスから読み書き可能でなければなりません。
                        書き込み可能なパスを指定しなかった場合は、
                        <classname>Zend_Session</classname> の開始時 (<methodname>start()</methodname> がコールされた場合)
                        に例外をスローします。
                    </para>
                    <note>
                        <title>セキュリティリスク</title>
                        <para>
                            そのパスが他のアプリケーションから読み取り可能になっていると、
                            セッションハイジャックの可能性が生じます。また、
                            他のアプリケーションから書き込み可能になっていると、
                            <ulink url="http://en.wikipedia.org/wiki/Session_poisoning">セッションポイズニング</ulink>
                            の可能性が生じます。このパスを他のユーザや他の PHP
                            アプリケーションと共有すると、さまざまなセキュリティ問題が発生します。
                            たとえばセッションの内容を盗まれたり、セッションをのっとられたり、
                            ガベージコレクションが衝突したり (たとえば、
                            別のユーザのアプリケーションによって、PHP
                            があなたのアプリケーションのセッションファイルを削除してしまう)
                            などの可能性があります。
                        </para>
                        <para>
                            たとえば、まず攻撃者が犠牲者のウェブサイトを訪問し、
                            セッションクッキーを取得します。そしてそのクッキーのパスを、
                            同一サーバにある彼のドメインに変更します。
                            それから彼自身のウェブサイトにいって
                            <methodname>var_dump($_SESSION)</methodname> を実行します。
                            犠牲者がセッションでどのようなデータを使用しているのかを知ったら、
                            次はセッションの状態を書き換え (セッションポイズニング)、
                            そのセッションを使用して改めて犠牲者のウェブサイトにリクエストを送ります。
                            それぞれのアプリケーションが、もう一方のアプリケーションの <code>save_path</code>
                            に対する読み書き権限を持っていなかったとしても、
                            もし <code>save_path</code> が推測可能な場所でかつ攻撃者が両方のアプリケーションを制御できるのなら、
                            攻撃者はその <code>save_path</code> を変更して自分のほうの
                            <code>save_path</code> を使うようにできます。
                            そしてこのようなセッションポイズニングは、一般的な設定の PHP
                            で実行可能なことがあります。
                            そのため、<code>save_path</code> の値は、ありがちな場所を避けるようにしなければなりません。
                            また、各アプリケーションで別々にし、安全を確保するようにしましょう。
                        </para>
                    </note>
                </listitem>
                <listitem>
                    <para>
                        string <code>name</code> -
                        正しい値はシステムに依存します。
                        アプリケーション間で <emphasis>一意</emphasis>
                        な値を開発者側で指定する必要があります。
                    </para>
                    <note>
                        <title>セキュリティリスク</title>
                        <para>
                            <code>php.ini</code> での <code>session.name</code> の設定が同じ
                            (たとえばデフォルトの "PHPSESSID") で、同一ドメインに複数の
                            PHP アプリケーションが存在する場合は、
                            両方のウェブサイトで同じセッションデータを共有することになってしまいます。
                            さらにその結果として、お互いのセッションデータが破壊されてしまう可能性があります。
                        </para>
                    </note>
                </listitem>
                <listitem>
                    <para>
                        boolean <code>use_only_cookies</code> -
                        以下で説明するセキュリティリスクを回避するため、
                        このオプションはデフォルトのままにしておいてください。
                        <note>
                            <title>セキュリティリスク</title>
                            <para>
                                もしこの設定を無効にすると、攻撃者は簡単に犠牲者のセッション
                                ID を盗めるようになります。攻撃者のウェブサイトへから、たとえば
                                <code>http://www.example.com/index.php?PHPSESSID=fixed_session_id</code>
                                のようなリンクを張るわけです。犠牲者がまだ example.com のセッション ID
                                クッキーを持っていない場合に、セッション固定化攻撃が成功します。
                                犠牲者がこの既知のセッション ID を使用するようになれば、
                                攻撃者はこのセッションを使用して犠牲者になりすまし、
                                犠牲者を装ってユーザエージェントを操作します。
                            </para>
                        </note>
                    </para>
                </listitem>
            </itemizedlist>
        </para>

    </sect2>

    <sect2 id="zend.session.global_session_management.headers_sent">

        <title>エラー: すでに送信されたヘッダ</title>

        <para>
            "Cannot modify header information - headers already sent"
            や "You must
            call .. before any output has been sent to the browser; output started in ..."
            のようなエラーが出た場合は、そのメッセージの直接の原因となった部分
            (関数あるいはメソッド) がどこなのかをきちんと調べましょう。
            HTTP ヘッダを送信するアクション、たとえばブラウザのクッキーの変更などは、
            通常の出力 (バッファリングされていない出力)
            の前に行う必要があります。ただし
            PHP の出力バッファリングを使用している場合は例外です。
        </para>

        <itemizedlist mark="opencircle">
            <listitem>
                <para>
                    常に
                    <ulink url="http://php.net/outcontrol">出力バッファリング</ulink>
                    を使用するようにすると、この問題を避けられます。またパフォーマンスも向上するでしょう。
                    たとえば <code>php.ini</code> で "<code>output_buffering = 65535</code>"
                    とすると、64K のバッファで出力バッファリングを行います。
                    出力バッファリングでパフォーマンスの向上を狙うことは
                    本番サーバでも有効な手法ですが、バッファリングだけでは
                    "headers already sent" 問題を解消するには不十分です。
                    アプリケーションで送信する内容がこのバッファサイズをこえないよう注意しましょう。
                    さもないと、(HTTP ヘッダの前に送信する出力が)
                    バッファサイズをこえた時点で断続的に問題が発生することでしょう。
                </para>
            </listitem>

            <listitem>
                <para>
                    もし <classname>Zend_Session</classname> のメソッドでエラーが発生しているのなら、
                    そのメソッドをよく見直してください。そのメソッドは、
                    必要な処理を本当に行っていますか?
                    たとえば、<methodname>destroy()</methodname> をデフォルトで使用すると、
                    HTTP ヘッダを送信してクライアント側のセッションクッキーを期限切れにします。
                    これが不要な場合は <methodname>destroy(false)</methodname> としてください。
                    HTTP においては、クッキーを書き換える (期限切れにするなど)
                    処理は HTTP ヘッダで行われます。
                </para>
            </listitem>
            <listitem>
                <para>
                    別の方法としては、アプリケーションのロジックを見直して
                    ヘッダを操作するアクションを
                    あらゆる出力の前に済ませてしまうことがあります。
                </para>
            </listitem>
            <listitem>
                <para>
                    PHP のソースファイルの最後でこのエラーが発生するのなら、
                    終了タグ "<code>?&gt;</code>" を削除しましょう。
                    これは不要です。また、終了タグの後に改行などの目に見えない文字があった場合、
                    それが出力としてクライアントに送信されてしまいます。
                </para>
            </listitem>
        </itemizedlist>

    </sect2>

    <sect2 id="zend.session.global_session_management.session_identifiers">

        <title>セッション識別子</title>

        <para>
            導入: Zend Framework でセッションを用いる際の最も推奨される方法は、
            ブラウザのクッキー (ブラウザに保存される、通常のクッキー)
            を使用することです。個々のユーザを追跡するために、一意な識別子を
            URL に埋め込むことは、お勧めしません。
            デフォルトでは、このコンポーネントは、
            クッキーのみを使用してセッション識別子を管理しています。
            クッキーの値が、ブラウザのセッションの一意な識別子となります。
            PHP の ext/session は、この識別子を使用して
            ウェブサイトの訪問者との一対一の対応を保持し、
            それぞれの訪問者ごとのセッションデータを持続して保持します。
            Zend_Session* は、この保存の仕組み (<code>$_SESSION</code>)
            をオブジェクト指向のインターフェイスでラップしたものです。
            残念ながら、もし攻撃者にクッキーの値 (セッション ID) がもれてしまうと、
            攻撃者はそのセッションをのっとることができるようになってしまいます。
            この問題は、PHP や Zend Framework に限ったものではありません。
            <methodname>regenerateId()</methodname> メソッドを使用すると、
            アプリケーション側でセッション ID (訪問者のクッキーに保存される値)
            を新しい値に変更できるようになります。この値は、
            ランダムで予測不可能です。
            注意: 厳密にいうと同じものではないのですが、この節では「ユーザエージェント」
            と「ウェブブラウザ」を同じ意味で使用しています。
            これは、読みやすさを考慮したためです。
        </para>

        <para>
            なぜ?: 攻撃者にセッション識別子を知られてしまうと、
            その攻撃者は別のユーザ (犠牲者) になりすますことができるようになります。
            そして、その犠牲者にしかアクセスできない情報を取得したり、
            犠牲者のデータを操作したりといったことが
            あなたのアプリケーションから行えるようになってしまうのです。
            セッション ID を変更することで、セッションハイジャックを防ぐことができます。
            セッション ID を変更した後は、変更後の値が攻撃者に知られない限り
            攻撃者は新しいセッション ID を使用できません。その結果、
            訪問者のセッションをのっとることができなくなります。
            仮に攻撃者が古いセッション ID を取得したとしても、
            <methodname>regenerateId()</methodname> はセッションデータを古いセッション ID
            から新しいほうに移すので、古いセッション ID
            からはどのデータにもアクセスできなくなります。
        </para>

        <para>
            いつ regenerateId() を使うのか?:
            <methodname>Zend_Session::regenerateId()</methodname> を Zend Framework
            の起動ファイルに追加するのが、もっとも安全かつ確実に
            ユーザエージェントのクッキーにあるセッション ID を再生成する方法です。
            セッション ID をいつ再生成するのかについての条件判断がない場合は、
            ここに追加しておくとよいでしょう。
            リクエストのたびに再生成するようにしておくと攻撃パターンのいくつかを防げますが、
            中にはそれによるパフォーマンスの劣化やネットワーク帯域への負荷がきになる人もいるでしょう。
            そこで、アプリケーション内でリスクの大きそうなところがどこかを判断し、
            その場面でだけセッション ID を再生成するということも一般に行われています。
            ウェブサイト訪問者のセッションの権限が「格上げされる」
            (自分の "プロフィール" を編集する前に再度認証を行うなど)
            際や、セキュリティ上「重要な」パラメータが変更される際などには、
            常に <methodname>regenerateId()</methodname> で新しいセッション ID
            を作成するようにしましょう。
            <methodname>rememberMe()</methodname> 関数をコールする際には、内部で自動的に
            <methodname>regenerateId()</methodname> がコールされます。
            ユーザがウェブサイトへのログインに成功したら、
            <methodname>regenerateId()</methodname> の代わりに <methodname>rememberMe()</methodname>
            を使うようにしましょう。
        </para>

        <sect3 id="zend.session.global_session_management.session_identifiers.hijacking_and_fixation">

            <title>セッションハイジャックおよびセッション固定化</title>

            <para>
                <ulink url="http://en.wikipedia.org/wiki/Cross_site_scripting">
                クロスサイトスクリプト (XSS) 脆弱性</ulink>
                を避けることは、セッションハイジャックを防ぐ助けになります。
                <ulink url="http://secunia.com/">Secunia の統計</ulink>
                によると、XSS 問題は頻繁に発生します。これは、
                ウェブアプリケーションの開発言語が何であっても同じです。
                XSS 問題が決して起こらないことを期待するよりも、
                もしそれが発生した場合の被害を最小限に抑える方法を考えましょう。
                XSS があれば、攻撃者は犠牲者のネットワークトラフィックに
                直接アクセスする必要がなくなります。
                犠牲者がすでにセッションクッキーを取得している場合、
                Javascript XSS があると攻撃者がそのクッキーを読み取り、
                セッションを盗むことができるようになります。
                犠牲者がまだセッションクッキーを持っていない場合は、
                攻撃者は XSS を使用して Javascript を注入し、
                犠牲者のブラウザに既知の値のセッション ID クッキーを作成します。
                そして同じクッキーを攻撃者のシステムに設定し、
                犠牲者のセッションをのっとります。
                犠牲者が攻撃者のウェブサイトを訪問すると、攻撃者は
                犠牲者のユーザエージェントに関するその他の特性もエミュレートできるようになります。
                あなたの作成するウェブサイトに XSS 脆弱性があると、
                攻撃者はそこに AJAX Javascript を仕込み、知らないうちに攻撃者のウェブサイトを
                「訪問」させてしまうことが可能になります。
                攻撃者はそれによって犠牲者のブラウザの特性を取得し、
                改ざんされたセッションでウェブサイトにアクセスするようになります。
                しかし、開発者が <code>save_path</code> オプションに正しい値を設定しておくと、
                攻撃者は PHP セッションのサーバ側の状態を任意に変更できることはなくなります。
            </para>

            <para>
                それ単体では、セッションを最初に使用する際に
                <methodname>Zend_Session::regenerateId()</methodname>
                をコールしてもセッション固定化攻撃は防げません。そのセッションが、
                攻撃者によって偽装されたものであるかどうかを判別できる必要があります。
                先ほど説明したこととは矛盾しているように感じられるかもしれません。
                しかしここで、攻撃者自身が
                まず最初にあなたのウェブサイトのセッションを開始した場合のことを考えてみましょう。
                セッションを "最初に使用" するのは攻撃者です。
                すると彼は、(<methodname>regenerateId()</methodname> による) 初期化の結果を知ることになります。
                その後、攻撃者や新しいセッション ID と XSS 脆弱性を組み合わせて使用するか、
                あるいは自分のウェブサイトにそのセッション ID
                を使用したリンクを埋め込みます
                (これは、<code>use_only_cookies = off</code> の場合にのみ動作します)。
            </para>

            <para>
                同じセッション ID を使用している場合に
                攻撃者と犠牲者を区別することができれば、
                セッションハイジャックを直接行うことはできなくなります。
                しかし、そのような区別を行うと、ユーザビリティが犠牲になってしまうことがあります。
                区別するための方法が明確ではないからです。
                たとえば、最初にセッションが作成されたときとは別の国に属する
                IP アドレスからリクエストを受け取った場合、
                そのリクエストはおそらく攻撃者からのものだと考えられます。
                しかし、次のような条件のもとでは、ウェブサイトへのアクセスが
                犠牲者からのものなのか攻撃者からのものなのかを区別する方法はありません。
                <itemizedlist mark='opencircle'>
                    <listitem>
                        <para>
                            攻撃者が、まずあなたのウェブサイトにアクセスし、
                            有効なセッション ID を取得する
                        </para>
                    </listitem>
                    <listitem>
                        <para>
                            あなたのウェブサイトの XSS 脆弱性を使用して、
                            取得したものと同じセッション ID
                            のクッキーを犠牲者のブラウザに送信する
                            (セッションの固定化)
                        </para>
                    </listitem>
                    <listitem>
                        <para>
                            犠牲者と攻撃者が、同じプロキシ群からアクセスしている
                            (両方ともが AOL のような大企業のファイアウォール内にいる場合など)
                        </para>
                    </listitem>
                </itemizedlist>
                以下のサンプルコードのようにすると、
                攻撃者が犠牲者の現在のセッション ID を知ることがはるかに困難になります。
                ただし、上で説明した最初のふたつのステップを実行していない場合に限ります。
            </para>

            <example id="zend.session.global_session_management.session_identifiers.hijacking_and_fixation.example">

                <title>セッション固定化</title>

                <programlisting language="php"><![CDATA[
$defaultNamespace = new Zend_Session_Namespace();

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

            </example>

        </sect3>

    </sect2>

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

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

        <para>
            通常は、セッションが終わるのはユーザエージェントが終了したとき、
            つまりユーザがウェブブラウザと閉じたときです。
            しかし、アプリケーション側で、ブラウザを閉じた後でもユーザセッションを有効にしておくこともできます。
            この機能を実現するには、持続クッキーを使用します。
            セッションの開始前に <methodname>Zend_Session::rememberMe()</methodname>
            を使用すると、セッションクッキーの有効期限を制御できます。
            秒数を指定しなかった場合は、セッションクッキーの持続期間はデフォルトの
            <code>remember_me_seconds</code> となります。このデフォルト値は
            <methodname>Zend_Session::setOptions()</methodname> で設定します。
            セッションの固定化/のっとり を防ぐには、
            ユーザがアプリケーションの認証を通過したとき (「ログイン」フォームなどから)
            にこの関数を使用します。
        </para>

    </sect2>

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

        <title>forgetMe()</title>

        <para>
            この関数は <methodname>rememberMe()</methodname> を補完するものです。
            セッションクッキーの有効期限を変更し、
            ユーザエージェントのセッションが終了したときに有効期限が切れるようにしたものを書き込みます。
        </para>

    </sect2>

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

        <title>sessionExists()</title>

        <para>
            このメソッドを使用して、現在のユーザエージェント/リクエスト
            に対応するセッションが既に存在するかどうかを調べます。
            これはセッションを開始する前に使用します。その他の
            <classname>Zend_Session</classname> および <classname>Zend_Session_Namespace</classname>
            のメソッドとは独立しています。
        </para>

    </sect2>

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

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

        <para>
            <methodname>Zend_Session::destroy()</methodname> は、
            現在のセッションに関連付けられているすべての持続的データを破棄します。
            しかし、PHP の変数の値は何の影響も受けません。
            したがって、名前空間つきのセッション
            (<classname>Zend_Session_Namespace</classname> のインスタンス)
            は読み込み可能な状態のままです。
            「ログアウト」を行うには、オプションのパラメータを <constant>TRUE</constant>
            (デフォルト) に設定し、
            ユーザエージェントのセッション ID クッキーを削除します。
            オプションのパラメータ <code>$readonly</code>
            を使用すると、<classname>Zend_Session_Namespace</classname> のインスタンスを作成したり
            <classname>Zend_Session</classname> のメソッドからセッションデータへ書き込んだりすることができなくなります。
        </para>

        <para>
            "Cannot modify header information - headers already sent"
            というエラーが出た場合は、最初の引数として <constant>TRUE</constant>
            (セッションクッキーを削除) を使用しないようにするか、あるいは
            <link linkend="zend.session.global_session_management.headers_sent">このセクション</link>を参照してください。
            つまり、<methodname>Zend_Session::destroy(true)</methodname> をコールするなら
            PHP が HTTP ヘッダを送信する前にするか、
            あるいは出力バッファリングを有効にしなければなりません。
            また、出力データの大きさが、設定したバッファサイズをこえてはいけません。
            これにより、<methodname>destroy()</methodname> のコール前に出力が送信されてしまうことを防ぎます。
        </para>

        <note>
            <title>例外/エラー</title>
            <para>
                デフォルトでは <code>$readonly</code> が有効になっています。
                そのため、セッションデータへの書き込みを含む操作を行うと、
                例外をスローします。
            </para>
        </note>

    </sect2>

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

        <title>stop()</title>

        <para>
            このメソッドは、単に <classname>Zend_Session</classname> のフラグを切り替え、
            セッションデータへの書き込みをできないようにするだけのものです。
            その他どのような機能を実装するかについては、フィードバックを受付中です。
            潜在的な使用法としては、一時的に
            <classname>Zend_Session_Namespace</classname> インスタンスや
            <classname>Zend_Session</classname> のメソッドから
            セッションデータに書き込めなくすることがあります。
            この場合、実行はビュー関連のコードに移譲されます。
            これらのインスタンスやメソッドからの書き込みを含むアクションは、
            例外をスローします。
        </para>

    </sect2>

    <sect2 id="zend.session.global_session_management.writeclose">

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

        <para>
            セッションを終了して内容を書き込んだ後に、
            <code>$_SESSION</code> をバックエンドから切り離します。
            これにより、このリクエストにおける内部データの変換が終了します。
            オプションのパラメータ <code>$readonly</code> を使用すると、書き込み権限をなくします
            (<classname>Zend_Session</classname> あるいは <classname>Zend_Session_Namespace</classname>
            のメソッドから書き込みを試みると、例外をスローします)。
        </para>

        <note>
            <title>例外/エラー</title>
            <para>
                デフォルトでは <code>$readonly</code> が有効になっています。
                そのため、セッションデータへの書き込みを含む操作を行うと、
                例外をスローします。
                しかし、既存のアプリケーションの中には、
                <methodname>session_write_close()</methodname> でセッションを終了した後でも
                <code>$_SESSION</code> に書き込み可能であることを想定しているものもあるでしょう。
                これが「最適な方法」だとは思いませんが、そのような場合のために
                <code>$readonly</code> オプションを用意しておきます。
            </para>
        </note>

    </sect2>

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

        <title><code>expireSessionCookie()</code></title>

        <para>
            このメソッドは、有効期限切れのセッション ID クッキーを送信し、
            クライアント側でセッションクッキーを削除させます。
            このテクニックを用いて、クライアント側でのログアウト機能を実現することもあります。
        </para>

    </sect2>

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

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

        <para>
            ほとんどの開発者にとっては、デフォルトの保存ハンドラで十分でしょう。
            このメソッドは、
            <ulink url="http://php.net/session_set_save_handler"><methodname>session_set_save_handler()</methodname></ulink>
            <ulink url="http://php.net/session_set_save_handler">session_set_save_handler()</ulink>
            のオブジェクト指向ラッパーです。
        </para>

    </sect2>

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

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

        <para>
            このメソッドを使用して、セッション名前空間が存在するかどうかを調べます。
            あるいは、特定の名前空間に特定のインデックスが存在するかどうかを調べます。
        </para>

        <note>
            <title>例外/エラー</title>
            <para>
                <classname>Zend_Session</classname> が読み取り可能に設定されていない場合
                (<classname>Zend_Session</classname> が開始される前など)
                に例外がスローされます。
            </para>
        </note>

    </sect2>

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

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

        <para>
            <methodname>Zend_Session::namespaceUnset($namespace)</methodname> を使用すると、
            名前空間全体およびその内容を効率的に削除できます。
            PHP のすべての配列と同様、
            配列を含む変数を初期化しても配列の中身のオブジェクトまでは初期化されません。
            もしそのオブジェクトへの参照が別の配列/オブジェクトにも格納されていたとすると、
            そちら経由でオブジェクトの内容にアクセスできてしまいます。
            したがって、<methodname>namespaceUnset()</methodname>
            によって名前空間のエントリの内容が "深いレベルまで"
            実際に削除されることはありません。
            さらに詳細な情報は、PHP マニュアルでの
            <ulink url="http://php.net/references">参照に関する説明</ulink>
            を参照ください。
        </para>

        <note>
            <title>例外/エラー</title>
            <para>
                名前空間が読み取り可能に設定されていない場合
                (<methodname>destroy()</methodname> の後など)
                に例外がスローされます。
            </para>
        </note>

    </sect2>

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

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

        <para>
            非推奨: <classname>Zend_Session_Namespace</classname> の <methodname>getIterator()</methodname>
            を使用しましょう。このメソッドは、<code>$namespace</code>
            の内容を配列で返します。このメソッドを外部から使用し続けたいという
            論理的な理由がある場合は、メーリングリスト
            <ulink url="mailto:fw-auth@lists.zend.com">fw-auth@lists.zend.com</ulink>
            にフィードバックをお願いします。
            ……っていうか、どんなネタでもいいのでメーリングリストに参加してください (^o^)
        </para>

        <note>
            <title>例外/エラー</title>
            <para>
                <classname>Zend_Session</classname> が読み取り可能に設定されていない場合
                (<classname>Zend_Session</classname> が開始される前など)
                に例外がスローされます。
            </para>
        </note>

    </sect2>

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

        <title>getIterator()</title>

        <para>
            <methodname>getIterator()</methodname> を使用して、全名前空間の名前を含む配列を取得します。
        </para>

        <note>
            <title>例外/エラー</title>
            <para>
                <classname>Zend_Session</classname> が読み取り可能に設定されていない場合
                (<classname>Zend_Session</classname> が開始される前など)
                に例外がスローされます。
            </para>
        </note>

    </sect2>

</sect1>