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

    <title>Globales Session Management</title>

    <para>
        Das Standardverhalten von Sessions kann mit Hilfe der statischen Methoden von
        <classname>Zend_Session</classname> geändert werden. Das komplette Management und die
        Manipulation des globalen Session Managements findet durch Verwendung von
        <classname>Zend_Session</classname> statt, was auch die Konfiguration der <ulink
            url="http://www.php.net/session#session.configuration">üblichen Optionen, welche von
            ext/session unterstützt werden</ulink>, durch
        <methodname>Zend_Session::setOptions()</methodname> enthält. Zum Beispiel kann, das
        fehlerhafte Versichern das ein sicherer <code>save_path</code> oder ein eindeutiger
        Cookiename von ext/session durch <methodname>Zend_Session::setOptions()</methodname>
        verwendet wird, zu einem Sicherheitsproblem werden.
    </para>

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

        <title>Konfigurations Optionen</title>

        <para>
            Wenn der erste Session Namensraum angefragt wird, startet
            <classname>Zend_Session</classname> automatisch die <acronym>PHP</acronym> Session,
            ausser er wurde bereits mit <link
                linkend="zend.session.advanced_usage.starting_a_session"><methodname>Zend_Session::start()</methodname></link>
            gestartet. Die darunterliegende <acronym>PHP</acronym> Session verwendet die Standards
            von <classname>Zend_Session</classname>, ausser wenn Sie schon durch
            <methodname>Zend_Session::setOptions()</methodname> modifiziert wurde.
        </para>

        <para>
            Um eine Konfigurations Option einer Session zu setzen, muß der Basisname (der Teil des
            Namens nach "<code>session.</code>") als Schlüssel eines Array inkludiert und an
            <methodname>Zend_Session::setOptions()</methodname> übergeben werden. Der
            korrespondierende Wert im Array wird verwendet um den Wert der Option dieser Session zu
            setzen. Wenn keine Option durch den Entwickler gesetzt wird, wird
            <classname>Zend_Session</classname> zuerst die benötigten Optionen anwenden und
            anschließend die standard php.ini Einstellungen. Feedback der Community über die beste
            Handhabung für diese Optionen sollte gesendet werden an <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>Verwenden von Zend_Config um Zend_Session zu konfigurieren</title>

            <para>
                Um diese Komponente mit Hilfe von <link
                    linkend="zend.config.adapters.ini"><classname>Zend_Config_Ini</classname></link>
                zu konfigurieren, muß zuerst die Konfigurations-Option dem <acronym>INI</acronym>
                File hinzugefügt werden:
            </para>

            <programlisting language="ini"><![CDATA[
; Accept defaults for production
[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 sollte für jede PHP Anwendung eindeutig sein und den
; selben Domain Namen verwenden
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

; Entwicklung beinhaltet Konfiguration der Produktion,
; überschreibt aber diverse Werte
[development : production]
; Nicht vergessen, dieses Verzeichnis zu erstellen und es
; rwx machen (lesbar und änderbar) durch PHP.
save_path = /home/myaccount/zend_sessions/myapp
use_only_cookies = on
; Beim Analysieren von Session ID Cookies, frage nach einer TTL von 10 Tagen
remember_me_seconds = 864000
]]></programlisting>

            <para>
                Als nächstes die Konfigurationsdatei laden und dessen Array Representation
                <methodname>Zend_Session::setOptions()</methodname> übergeben:
            </para>

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

require_once 'Zend/Session.php';
Zend_Session::setOptions($config->toArray());
]]></programlisting>

        </example>

        <para>
            Die meisten der oben gezeigten Optionen benötigen keine Erklärung die nicht in der
            Standard <acronym>PHP</acronym> Dokumentation gefunden werden kann, aber jene von
            speziellem Interesse sind anbei beschrieben.
            <itemizedlist mark="opencircle">
                <listitem>
                    <para>
                        boolean <code>strict</code> - verhindert das automatische Starten von
                        <classname>Zend_Session</classname> wenn <code>new
                        Zend_Session_Namespace()</code> verwendet wird.
                    </para>
                </listitem>
                <listitem>
                    <para>
                        integer <code>remember_me_seconds</code> - Wie lange soll das Session Id
                        Cookie bestehen, nachdem der Benutzer Agent beendet wurde (z.B. Browser
                        Anwendung geschlossen)
                    </para>
                </listitem>
                <listitem>
                    <para>
                        string <code>save_path</code> - Der richtige Wert ist abhängig vom System,
                        und sollte vom Entwickler auf einen <emphasis>absoluten Pfad</emphasis> zu
                        einem Verzeichnis bereitgestellt werden, welches durch den
                        <acronym>PHP</acronym> Prozess lesbar und beschreibbar ist. Wenn kein
                        schreibbarer Pfad gegeben ist, wird <classname>Zend_Session</classname> eine
                        Ausnahme werden sobald Sie gestartet wird (z.B. wenn
                        <methodname>start()</methodname> aufgerufen wird).
                    </para>
                    <note>
                        <title>Sicherheits Risiko</title>
                        <para>
                            Wenn der Pfad von einer anderen Anwendung aus lesbar ist, kann die
                            Entführung der Session möglich sein. Wenn der Pfad von einer anderen
                            Anwendung aus beschreibbar ist, kann die <ulink
                                url="http://en.wikipedia.org/wiki/Session_poisoning">Session
                            vergiftet</ulink> werden. Wenn der Pfad mit anderen Benutzern oder
                            anderen <acronym>PHP</acronym> Anwendungen geteilt wird, können
                            verschiedenste Sicherheitsprobleme auftreten. Das inkludiert Diebstahl
                            von Inhalten der Session, Entführung von Sessions und Kollisionen der
                            Müllsammlung (z.B., eine andere Anwendung eines Benutzers können
                            <acronym>PHP</acronym> veranlassen die eigenen Session Dateien zu
                            löschen).
                        </para>
                        <para>
                            Zum Beispiel kann ein Angreifer die Webseite des Opfers besuchen um ein
                            Session Cookie zu erhalten. Dann, den Cookie Pfad auf die eigene Domain
                            auf dem gleichen Server ändern, bevor er die eigene Webseite besucht um
                            <methodname>var_dump($_SESSION)</methodname> auszuführen. Bewaffnet mit
                            detailiertem Wissen über die Verwendung von Daten in den Sessions des
                            Opfers, kann der Angreifer den Sessionstatus verändern (Vergiften der
                            Session), den Cookie Pfad auf die Webseite des Opfers zurück ändern, und
                            anschließend eine Anfrage von der Webseite des Opfers, mithilfe der
                            vergifteten Session, durchführen. Selbst wenn zwei Anwendungen auf dem
                            gleichen Server keinen Lese-/Schreibzugriff auf den jeweils anderen
                            <code>save_path</code> der Anwendung haben, wenn der
                            <code>save_path</code> erahnbar ist und der Angreifer die Kontrolle über
                            eine der zwei Webseiten hat, kann der Angreifer den
                            <code>save_path</code> seiner Webseiten ändern um dem anderen save_path
                            zu verwenden und somit die Vergiftung der Session durchführen, in den
                            meisten üblichen <acronym>PHP</acronym> Konfigurationen. Deshalb sollte
                            der Wert für <code>save_path</code> nicht öffentlich bekanntgegeben
                            werden, und er sollte geändert werden um dem Pfad eindeutig für jede
                            Anwendung zu sichern.
                        </para>
                    </note>
                </listitem>
                <listitem>
                    <para>
                        string <code>name</code> - Der richtige Wert ist abhängig vom System and
                        sollte vom Entwickler, durch Verwenden eines bestimmten Wertes,
                        bereitgestellt werden, welcher für jede Zend Framework Anwendung
                        <emphasis>eindeutig</emphasis> ist.
                    </para>
                    <note>
                        <title>Sicherheits Risiko</title>
                        <para>
                            Wenn die <code>php.ini</code> Einstellung für <code>session.name</code>
                            die selbe ist (z.B., die standardmäßige "PHPSESSID"), und es zwei oder
                            mehr <acronym>PHP</acronym> Anwendungen gibt die über den selben Domain
                            Namen erreichbar sind, dann werden Sie miteinander für alle Besucher die
                            beide Webseiten besuchen, die selben Session Daten teilen. Zusätzlich,
                            könnte das auch zu einer Verfälschung von Session Daten führen.
                        </para>
                    </note>
                </listitem>
                <listitem>
                    <para>
                        boolean <code>use_only_cookies</code> - Um zusätzliche Sicherheitsrisiken
                        zu vermeiden, sollte der Standardwert dieser Option nicht verändert werden.
                        <note>
                            <title>Sicherheits Risiko</title>
                            <para>
                                Wenn diese Einstellung nicht aktiviert wird, kann ein Angreifer
                                einfach die Session Id des Opfers ändern indem ein Link auf der
                                Webseite des Angreifers verwendet wird, wie z.B.
                                <code>http://www.example.com/index.php?PHPSESSID=fixed_session_id</code>.
                                Die Änderung funtioniert, wenn das Opfer nicht schon ein Session Id
                                Cookie für example.com besitzt. Sobald ein Opfer eine bekannte
                                Session Id benutzt, kann der Angreifer versuchen die Session zu
                                übernehmen indem er sich verstellt und vorgibt das Opfer zu sein,
                                und den UserAgent des Opfers emuliert.
                            </para>
                        </note>
                    </para>
                </listitem>
            </itemizedlist>
        </para>

    </sect2>

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

        <title>Fehler: Header schon gesendet</title>

        <para>
            Wenn die Fehler Nachricht, "Cannot modify header information - headers already sent",
            oder "You must call .. before any output has been sent to the browser; output started
            in ..." erscheint, sollte der direkte Grund (Funktion oder Methode) der mit dieser
            Nachricht gekoppelt ist sorgfältig begutachtet werden. Jede Aktion die das senden von
            <acronym>HTTP</acronym> Headern benötigt, wie z.B. das modifizieren von Browser Cookies,
            muß vor dem Senden von normaler Ausgabe (ungepufferter Ausgabe) durchgeführt werden,
            ausser wenn <acronym>PHP</acronym>'s Ausgabebuffer verwendet wird.
        </para>

        <itemizedlist mark='opencircle'>
            <listitem>
                <para>
                    <ulink url="http://php.net/outcontrol">Puffern der Ausgabe</ulink> ist oft
                    notwendig um dieses Problem zu verhindern, und hilft bei der Steigerung der
                    Geschwindigkeit. Zum Beispiel aktiviert "<code>output_buffering = 65535</code>"
                    in der <code>php.ini</code> das Puffern der Ausgabe mit einem 64k Puffer. Selbst
                    wenn das Puffern der Ausgabe eine gute Taktik ist um auf Produktionsservern die
                    Geschwindigkeit zu Erhöhen, ist das Vertrauen auf das Puffern, um das Problem
                    "headers already sent" zu beheben, nicht ausreichend. Die Anwendung darf die
                    Buffergröße nicht überschreiten, andernfalls wird das Problem von Zeit zu Zeit
                    wieder auftreten, wann auch immer eine Ausgabe gesendet wird (vor den
                    <acronym>HTTP</acronym> Headern) die die Puffergröße überschreitet.
                </para>
            </listitem>
            <listitem>
                <para>
                    Anternativ kann versucht werden die Logik der Anwendung anders anzuordnen, so
                    das Aktionen welche Header manipulieren vor dem Senden von jeglicher Ausgabe
                    ausgeführt werden.
                </para>
            </listitem>
            <listitem>
                <para>
                    Wenn eine Methode von <classname>Zend_Session</classname> als Verursacher der
                    Fehlermeldung ist, sollte die Methode sorgfältig begutachtet werden und es ist
                    sicher zu stellen das Sie auch wirklich in der Anwendung benötigt wird. Zum
                    Beispiel sendet auch die standardmäßige Verwendung von
                    <methodname>destroy()</methodname> einen <acronym>HTTP</acronym> Header um das
                    Session Cookie auf der Seite des Clients ablaufen zu lassen. Wenn das nicht
                    benötigt wird sollte <methodname>destroy(false)</methodname> verwendet werden,
                    da die Anweisungen für das Ändern von Cookies im <acronym>HTTP</acronym> Header
                    gesendet.
                </para>
            </listitem>
            <listitem>
                <para>
                    Anternativ kann versucht werden die Logik der Anwendung anders anzuordnen, so
                    das Aktionen welche Header manipulieren vor dem Senden von jeglicher Ausgabe
                    ausgeführt werden.
                </para>
            </listitem>
            <listitem>
                <para>
                    Jedes schließende "<code>?&gt;</code>" Tag sollte entfernt werden, wenn es am
                    Ende einer <acronym>PHP</acronym> Source Datei steht. Sie werden nicht benötigt
                    und neue Zeilen und andere beinahe unsichtbare Leerzeichen welche dem
                    schließenden Tag folgen können eine Ausgabe an den Client verursachen.
                </para>
            </listitem>
        </itemizedlist>

    </sect2>

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

        <title>Session Identifizierer</title>

        <para>
            Einführung: Die beste Praxis in Relation für die Benutzung von Session innerhlab des ZF
            fordert die Verwendung eines Browser Cookies (z.B. ein normales Cookie welchem im Web
            Browser gespeichert wird), statt der integration von eindeutigen Session Identifizierern
            in <acronym>URL</acronym>s als Mittel für das verfolgen von individuellen Benutzern.
            Normalerweise verwendet diese Komponente nur Cookie für die Handhabung von Session
            Identifizierern. Der Wert des Cookies ist der eindeutige Identifizierer in der Session
            des Browsers. <acronym>PHP</acronym>'s ext/session verwendet diesen Identifizierer um
            eine eindeutige eins-zu-eins Verbindung zwischen dem Besucher der Webseite und dem
            dauerhaften Session Daten Speicher herzustellen. <classname>Zend_Session</classname>*
            umhüllt diesen Speichermechanismus (<varname>$_SESSION</varname>) mit einem
            objektorientierten Interface. Leider, wenn ein Angreifer Zugriff auf der Wert des
            Cookies (die Session Id) erhält, kann er die Session des Besuchers übernehmen. Dieses
            Problem gilt nicht nur für <acronym>PHP</acronym> oder den Zend Framework. Die
            <methodname>regenerateId()</methodname> Methode erlaubt einer Anwendung die Session Id
            (die im Cookie des Besuchers gespeichert ist) in einen neuen, zufälligen,
            unvorhersagbaren Wert zu ändern. Achtung: Auch wenn nicht das gleiche gemeint ist, um
            diese Sektion einfacher lesbar zu machen, verwenden wir die Ausdrücke "User Agent" und
            "Webbrowser" synonym füreinander.
        </para>

        <para>
            Warum?: Wenn ein Angreifer einen gültigen Session Identifizierer erhält, kann ein
            Angreifer einen gültigen Benutzer (das Opfer) verkörpern, und anschließend Zugriff auf
            vertrauliche Intormationen oder andererseits die Daten des Opfers verändern welche von
            der Anwendung verwaltet werden. Das Ändern des Session Id's hilft sich gegen die
            Übernahme der Session zu Schützen. Wenn die Session Id geändert wird, und ein Angreifer
            den neuen Wert nicht weiß, kann der Angreifer die neue Session Id nicht für Ihren Zweck,
            dem Versuch der Übernahme der Session des Opfers, verwenden. Selbst wenn der Angreifer
            zugriff auf die alte Session Id erhält, verschiebt
            <methodname>regenerateId()</methodname> die Daten der Session vom alten Session Id
            "Handle" zum neuen, weswegen keine Daten über die alte Session Id abrufbar sind.
        </para>

        <para>
            Wann sollte regenerateId() verwendet werden: Das Hinzufügen von
            <methodname>Zend_Session::regenerateId()</methodname> in die Bootstrap Datei des Zend
            Frameworks bietet einen der sichersten und am besten geschützten Wege um die Session
            Id's in den Cookies der User Agenten zu erneuern. Wenn es keine bedingte Logik gibt, um
            herauszufinden wann die Session Id erneuert werden soll, dann gibt es keinen Mangel in
            dieser Logik. Auch wenn der Erneuern bei jeder Anfrage einen möglichen Weg der Attacke
            verhindert, will nicht jedermann die damit hervorgerufenen kleinen Einbußen in der
            Geschwindigkeit und der Bandbreite hinnhmen. Deswegen versuchen Anwendungen
            normalerweise Situationen von größerem Risiko zu erahnen, und nur in diesen Situationen
            die Session Id's zu erneuern. Immer wenn die Rechte einer Session vom Besucher der
            Webseite "ausgeweitet" werden (z.B. ein Besucher muß noch einmal seine Identität
            authentifizieren bevor sein "Profil" bearbeitet werden darf), oder wann auch immer ein
            sicherheits-"sensitiver" Session Parameter geändert wird, sollte daran gedacht werden
            <methodname>regenerateId()</methodname> zu verwenden um eine neue Session Id zu
            erstellen. Wenn die <methodname>rememberMe()</methodname> Funktion aufgerufen wird,
            sollte <methodname>regenerateId()</methodname> nicht verwendet werden, ausser der
            erstere ruft den letzteren auf. Wenn sich ein Benutzer erfolgreich auf die Webseite
            eingeloggt hat, sollte <methodname>rememberMe()</methodname> statt
            <methodname>regenerateId()</methodname> verwendet werden.
        </para>

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

            <title>Session-Entführung und Fixierung</title>

            <para>
                Das Vermeiden von
                <ulink url="http://en.wikipedia.org/wiki/Cross_site_scripting">Seiten übergreifenden
                Script (XSS) Gefährdungen</ulink> hilft bei der Vorbeugung von Session Entführungen.
                Laut <ulink url="http://secunia.com/">Secunia's</ulink> Statistik kommen XSS
                Probleme häufig vor, unabhängig von der Sprache dir für die Erstellung der Web
                Anwendung benutzt wurde. Vor der Annahme nie XSS Probleme mit einer Anwendung zu
                haben, sollten diese mit der folgenden besten Praxis berücksichtigt werden um, wenn
                sie auftreten, den geringsten Schaden zu haben. Mit XSS benötigt ein Angreifer
                keinen direkten Zugriff auf den Netzwerk Verkehr des Opfers. Wenn das Opfer bereits
                ein Session Cookie hat, kann Javascript XSS einem Angreifer erlauben das Cookie zu
                lesen und die Session zu stehlen. Für Opfer ohne Session Cookies, kann ein
                Angreifer, wenn er XSS verwendet um Javascript einzuschleusen, ein Session Id Cookie
                mit einem bekannten Wert, auf dem Browser des Opfers erstellen, und dann ein
                identisches Cookie auf dem System des Angreifers setzen, um die Session des Opfers
                zu entführen. Wenn das Opfer die Webseite des Angreifers besucht, kann der Angreifer
                auch die meisten anderen infizierbaren Characteristiken vom User Agent des Opfers
                emulieren. Wenn eine Webseite eine XSS Gefährdung aufweist, könnte der Angreifer ein
                <acronym>AJAX</acronym> Javascript einfügen das versteckt die Webseite des
                Angreifers "besucht", damit der Angreifer die Characteristika vom Browser des Opfers
                weiß und auf die beeinträchtigte Session auf der Webseite des Opfers aufmerksam
                gemacht wird. Trotzdem kann ein Angreifer nicht willkürlich die serverseitigen
                Status der <acronym>PHP</acronym> Session ändern, wenn der Entwickler den Wert für
                die <code>save_path</code> Option richtig eingestellt hat.
            </para>

            <para>
                Nur durch das Aufrufen von <methodname>Zend_Session::regenerateId()</methodname>,
                wenn die Session des Benutzers das erste Mal verwendet wird, verhindert keine
                Session Fixierungs Attacken, ausser es kann die Session, die von einem Angreifer
                erstellt wurde um ein Opfer zu Emulieren, unterschieden werden. Das könnte zuerst
                wiedersprüchlich klingen zu dem vorherigen Statement, solange angenommen wird das
                ein Angreifer zuerst eine reale Session auf der Webseite initiiert. Die Session wird
                "zuerst vom Angreifer benutzt", welche dann das Ergebnis der Initialisierung weiß
                (<methodname>regenerateId()</methodname>). Der Angreifer verwendet dann diese neue
                Session Id in Kombination mit der XSS Gefährdung, oder injiziert die Session Id über
                einen Link auf der Webseite des Angreifers (funktioniert wenn
                <code>use_only_cookies = off</code>).
            </para>

            <para>
                Wenn zwischen einem Angreifer und einem Opfer welche die selbe Session Id verwenden,
                unterschieden werden kann, kann mit der Session Enführung direkt gehandelt werden.
                Trotzdem beinhalten solche Formen von Unterscheidungen normalerweise eine
                Verringerung der Handhabung weil diese Methoden der Unterscheidung oft ungenau sind.
                Wenn, zum Beispiel, eine Anfrage von einer IP in einem anderen Land empfangen wird
                als von der IP in welchem die Session erstellt wurde, gehört die neue Anfrage
                möglicherweise zu einem Angreifer. Unter der folgenden Annahme, gibt es
                möglicherweise keinen Weg, für eine Webseiten Anwendung, zwischen einem Opfer und
                einem Angreifer zu unterscheiden:
                <itemizedlist mark='opencircle'>
                    <listitem>
                        <para>
                            Der Angreifer initiiert eine Session auf der Webseite um eine gültige
                            Session Id zu erhalten
                        </para>
                    </listitem>
                    <listitem>
                        <para>
                            Der Angreifer benutzt XSS Gefährdungen auf der Webseite um ein Cookie
                            auf dem Browser des Opfers mit der geichen, gültigen Session Id (z.b.
                            Session Fixierung), zu erstellen
                        </para>
                    </listitem>
                    <listitem>
                        <para>
                            Beide, das Opfer und der Angreifer kommen von der selben Proxy Farm
                            (z.B. wenn beide hinter der selben Firewall einer großen Firma, wie AOL,
                            sind)
                        </para>
                    </listitem>
                </itemizedlist>
                Der Beispiel-Code anbei, macht es für Angreifer viel schwerer die aktuelle Session
                Id des Opfers zu wissen solange der Angreifer nicht bereits die ersten Zwei Schritte
                von oben ausgeführt hat.
            </para>

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

                <title>Session Fixierung</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>
            Normalerweise enden Sessions wenn der User Agent terminiert, wie wenn der End-Benutzer
            seinen WebBrowser schließt. Trotzdem kann die Anwendung die Möglichkeit bieten, eine
            Benutzer Session über die Lebensdauer des Client Programms hinweg zu verlängern durch
            die Verwendung von persistenten Cookies.
            <methodname>Zend_Session::rememberMe()</methodname> kann vor dem Start der Session
            verwendet werden um die Zeitdauer zu kontrollieren bevor ein persistentes Session Cookie
            abläuft. Wenn keine Anzahl an Sekunden definiert wird, verwendet das Session Cookie
            standardmäßig eine Lebenszeit von <code>remember_me_seconds</code>, welche durch
            Verwendung von <methodname>Zend_Session::setOptions()</methodname> gesetzt werden kann.
            Um zu helfen eine Session Fixierung/Entführung zu vereiteln, sollte diese Funktion
            verwendet werden wenn sich ein Benutzer erfolgreich an der Anwendung authentifiziert hat
            (z.B., durch ein "login" Formular).
        </para>

    </sect2>

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

        <title>forgetMe()</title>

        <para>
            Diese Funktion ist das Gegenteil von <methodname>rememberMe()</methodname> durch
            Schreiben eines Session Cookies das eine Lebenszeit hat die endet wenn der Benutzer
            terminiert.
        </para>

    </sect2>

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

        <title>sessionExists()</title>

        <para>
            Diese Methode kann verwendet werden um Herauszufinden ob eine Session für den aktuellen
            User Agent/Anfrage bereits existiert. Das kann vor dem Starten einer Session verwendet
            werden, und ist unabhängig von allen anderen <classname>Zend_Session</classname> und
            <classname>Zend_Session_Namespace</classname> Methoden.
        </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> entfernt alle deuerhaften Daten welche
            mit der aktuellen Session verbunden sind. Aber es werden keine Variablen in
            <acronym>PHP</acronym> verändert, so das die benannte Session (Instanzen von
            <classname>Zend_Session_Namespace</classname>) lesbar bleibt. Es ein "Logout"
            fertigzustellen, muß der optionale Parameter auf <constant>TRUE</constant> (standard)
            gesetzt werden um auch das Session Id Cookie des User Agents zu löschen. Der optionale
            <varname>$readonly</varname> Parameter entfernt die Möglichkeit neue
            <classname>Zend_Session_Namespace</classname> Instanzen zu erstellen und für
            <classname>Zend_Session</classname> in den Session Daten Speicher zu schreiben.
        </para>

        <para>
            Wenn die Fehlermeldung "Cannot modify header information - headers already sent"
            erscheint, sollte entweder die Verwendung von <constant>TRUE</constant> als Wert für das
            erste Argument (die Entfernung des Session Cookies anfragen) vermieden werden, oder
            unter <xref linkend="zend.session.global_session_management.headers_sent" /> nachgesehen
            werden. Deswegen muß entweder <methodname>Zend_Session::destroy(true)</methodname>
            aufgerufen werden bevor <acronym>PHP</acronym> <acronym>HTTP</acronym> Header gesendet
            hat, oder die Pufferung der Ausgabe muß aktiviert sein. Auch die komplette Ausgabe die
            gesendet werden soll, darf die gesetzte Puffergröße nicht überschreiten, um das Senden
            der Ausgabe vor dem Aufruf von <methodname>destroy()</methodname> zu Verhindern.
        </para>

        <note>
            <title>Wirft</title>
            <para>
                Standardmäßig ist <varname>$readonly</varname> aktiviert, und weitere Aktionen
                welche das Schreiben in den Session Daten Speicher beinhalten, werfen eine Ausnahme.
            </para>
        </note>

    </sect2>

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

        <title>stop()</title>

        <para>
            Diese Methode macht nicht mehr als ein Flag in <classname>Zend_Session</classname> zu
            wechseln um weiteres Schreiben in den Session Daten Speicher zu verhindern. Wir erwarten
            spezielles Feedback für dieses Feature. Potentielle Nicht-/Verwendung könnte temporär
            bei Verwendung von <classname>Zend_Session_Namespace</classname> Instanzen oder
            <classname>Zend_Session</classname> Methoden verhindern das auf den Session Daten
            Speicher geschrieben wird, wärend deren Ausführung zum Code der View transferiert wird.
            Versuche Aktionen auszuführen welche das Schreiben über diese Instanzen oder Methoden
            inkludieren werden eine Ausnahme werfen.
        </para>

    </sect2>

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

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

        <para>
            Beendet die Session, schließt das schreiben und entfernt <varname>$_SESSION</varname>
            vom Backend Speicher Mechanismus. Das vervollständigt die interne Transformation der
            Daten auf diese Anfrage. Der optionale boolsche <varname>$readonly</varname> Parameter
            kann den Schreibzugriff entfernen durch das werfen einer Ausnahme bei jedem Versuch in
            eine Session durch <classname>Zend_Session</classname> oder
            <classname>Zend_Session_Namespace</classname> zu schreiben.
        </para>

        <note>
            <title>Wirft</title>
            <para>
                Standardmäßig ist <varname>$readonly</varname> aktiviert und weitere Aktionen welche
                in den Session Daten Speicher schreiben werfen eine Ausnahme. Trotzdem könnten
                einige besondere Anwendungen erwarten das <varname>$_SESSION</varname> beschreibbar
                bleibt nachdem die Session mittels <methodname>session_write_close()</methodname>
                beendet wurde. Obwohl das nicht die "beste Praxis" ist, ist die
                <varname>$readonly</varname> für jene vorhanden die Sie benötigen.
            </para>
        </note>

    </sect2>

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

        <title>expireSessionCookie()</title>

        <para>
            Diese Methode sendet ein abgelaufenes Session Id Cookie, was den Client dazu bringt den
            Session Cookie zu löschen. Manchmal wird diese Technik dazu verwendet einen Logout auf
            der Seite des Client auszuführen.
        </para>

    </sect2>

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

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

        <para>
            Die meisten Entwickler werden den Standardmäßigen Speicher Handle ausreichend finden.
            Diese Methode bietet einen objekt-orientierten Wrapper für <ulink
                url="http://php.net/session_set_save_handler"><methodname>session_set_save_handler()</methodname></ulink>.
        </para>

    </sect2>

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

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

        <para>
            Diese Methode kann dazu verwendet werden um herauszufinden ob ein Session Namensraum
            existiert, oder ob ein bestimmter Index in einem bestimmten Namensraum existiert.
        </para>

        <note>
            <title>Wirft</title>
            <para>
                Eine Ausnahme wird geworfen wenn <classname>Zend_Session</classname> nicht als
                lesbar markiert ist (z.B. bevor <classname>Zend_Session</classname> gestartet
                wurde).
            </para>
        </note>

    </sect2>

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

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

        <para>
            <methodname>Zend_Session::namespaceUnset($namespace)</methodname> kann verwendet werden
            um effektiv den kompletten Namensraum und dessen Inhalt zu entfernen. Wie mit allen
            Arrays in <acronym>PHP</acronym>, wenn eine Variable die ein Array enthält entfernt
            wird, und das Array andere Objekte enthält, werden diese verfügbar bleiben, wenn diese
            durch Referenz in anderen Array/Objekten gespeichert sind, die durch anderen Variablen
            erreichbar bleiben. <methodname>namespaceUnset()</methodname> führt kein "tiefes"
            entfernen/löschen von Inhalten eines Eintrages im Namensraum durch. Für eine
            detailiertere Erklärung sollte im <acronym>PHP</acronym> Handbuch unter <ulink
                url="http://php.net/references">Referenzen erklärt</ulink> nachgesehen werden.
        </para>

        <note>
            <title>Wirft</title>
            <para>
                Eine Ausnahme wird geworfen wenn der Namensraum nicht beschreibbar ist (z.B. nach
                <methodname>destroy()</methodname>).
            </para>
        </note>

    </sect2>

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

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

        <para>
            DEPRECATED: <methodname>getIterator()</methodname> in
            <classname>Zend_Session_Namespace</classname> sollte verwendet werden. Diese Methode
            gibt ein Array mit dem Inhalt von <varname>$namespace</varname> zurück. Wenn es logische
            Gründe gibt diese Methode öffentlich aufrufbar zu lassen bitte ein Feedback auf die
            <ulink url="mailto:fw-auth@lists.zend.com">fw-auth@lists.zend.com</ulink> Mailingliste
            geben. Aktuell ist jede Anteilnahme an irgendeinem relevanten Thema sehr willkommen :)
        </para>

        <note>
            <title>Wirft</title>
            <para>
                Eine Ausnahme wird geworfen wenn <classname>Zend_Session</classname> nicht als
                lesbar markiert ist (z.B bevor <classname>Zend_Session</classname> gestartet wurde).
            </para>
        </note>

    </sect2>

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

        <title>getIterator()</title>

        <para>
            <methodname>getIterator()</methodname> kann verwendet werden, um ein Array zu erhalten,
            das die Namen aller Namensräume enthält.
        </para>

        <note>
            <title>Wirft</title>
            <para>
                Eine Ausnahme wird geworfen wenn <classname>Zend_Session</classname> nicht als
                lesbar markiert ist (z.B. bevor <classname>Zend_Session</classname> gestartet
                wurde).
            </para>
        </note>

    </sect2>

</sect1>
