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

<?xml version="1.0" encoding="UTF-8"?>
<!-- EN-Revision: 15346 -->
<!-- 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 Zend_Session
        geändert werden. Das komplette Management und die Manipulation des globalen Session
        Managements findet durch Verwendung von Zend_Session 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
        <classname>Zend_Session::setOptions()</classname> enthält. Zum Beispiel kann, das
        fehlerhafte Versichern das ein sicherer <code>save_path</code> oder ein eindeutiger
        Cookiename von ext/session durch <classname>Zend_Session::setOptions()</classname> 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 Zend_Session automatisch die
            PHP Session, ausser er wurde bereits mit <link
                linkend="zend.session.advanced_usage.starting_a_session"><classname>Zend_Session::start()</classname></link>
            gestartet. Die darunterliegende PHP Session verwendet die Standards von Zend_Session,
            ausser wenn Sie schon durch <classname>Zend_Session::setOptions()</classname>
            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
            <classname>Zend_Session::setOptions()</classname> ü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 Zend_Session 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 INI File hinzugefügt
                werden:
            </para>

            <programlisting role="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
                <classname>Zend_Session::setOptions()</classname> übergeben:
            </para>

            <programlisting role="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 PHP 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 PHP 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 <code>start()</code> 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 PHP 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 PHP 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
                            <code>var_dump($_SESSION)</code> 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 PHP 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 ZF 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 PHP 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
            HTTP 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 PHP'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 HTTP
                    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 Zend_Session 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 <code>destroy()</code> einen HTTP
                    Header um das Session Cookie auf der Seite des Clients ablaufen zu lassen. Wenn
                    das nicht benötigt wird sollte <code>destroy(false)</code> verwendet werden, da
                    die Anweisungen für das Ändern von Cookies im HTTP 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 PHP 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 URLs 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. PHP'
            ext/session verwendet diesen Identifizierer um eine eindeutige eins-zu-eins Verbindung
            zwischen dem Besucher der Webseite und dem dauerhaften Session Daten Speicher
            herzustellen. Zend_Session* umhüllt diesen Speichermechanismus (<code>$_SESSION</code>)
            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 PHP oder den Zend Framework. Die
            <code>regenerateId()</code> 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 <code>regenerateId()</code> 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
            <classname>Zend_Session::regenerateId()</classname> 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
            <code>regenerateId()</code> zu verwenden um eine neue Session Id zu erstellen. Wenn die
            <code>rememberMe()</code> Funktion aufgerufen wird, sollte <code>regenerateId()</code>
            nicht verwendet werden, ausser der erstere ruft den letzteren auf. Wenn sich ein
            Benutzer erfolgreich auf die Webseite eingeloggt hat, sollte <code>rememberMe()</code>
            statt <code>regenerateId()</code> 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
                AJAX 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 PHP
                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 <classname>Zend_Session::regenerateId()</classname>, 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ß
                (<code>regenerateId()</code>). 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 role="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.
            <classname>Zend_Session::rememberMe()</classname> 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 <classname>Zend_Session::setOptions()</classname> 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 <code>rememberMe()</code> 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>
            <classname>Zend_Session::destroy()</classname> entfernt alle deuerhaften Daten welche
            mit der aktuellen Session verbunden sind. Aber es werden keine Variablen in PHP
            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 <code>true</code> (standard) gesetzt
            werden um auch das Session Id Cookie des User Agents zu löschen. Der optionale
            <code>$readonly</code> 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 <code>true</code> 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 <classname>Zend_Session::destroy(true)</classname>
            aufgerufen werden bevor PHP 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
            <code>destroy()</code> zu Verhindern.
        </para>

        <note>
            <title>Wirft</title>
            <para>
                Standardmäßig ist <code>$readonly</code> 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 Zend_Session 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 <code>$_SESSION</code> vom
            Backend Speicher Mechanismus. Das vervollständigt die interne Transformation der Daten
            auf diese Anfrage. Der optionale boolsche <code>$readonly</code> 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 <code>$readonly</code> aktiviert und weitere Aktionen welche in
                den Session Daten Speicher schreiben werfen eine Ausnahme. Trotzdem könnten einige
                besondere Anwendungen erwarten das <code>$_SESSION</code> beschreibbar bleibt
                nachdem die Session mittels <code>session_write_close()</code> beendet wurde. Obwohl
                das nicht die "beste Praxis" ist, ist die <code>$readonly</code> 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"><code>session_set_save_handler()</code></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>
            <classname>Zend_Session::namespaceUnset($namespace)</classname> kann verwendet werden
            um effektiv den kompletten Namensraum und dessen Inhalt zu entfernen. Wie mit allen
            Arrays in PHP, 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.
            <code>namespaceUnset()</code> führt kein "tiefes" entfernen/löschen von Inhalten eines
            Eintrages im Namensraum durch. Für eine detailiertere Erklärung sollte im PHP 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
                <code>destroy()</code>).
            </para>
        </note>

    </sect2>

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

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

        <para>
            DEPRECATED: <code>getIterator()</code> in <classname>Zend_Session_Namespace</classname>
            sollte verwendet werden. Diese Methode gibt ein Array mit dem Inhalt von
            <code>$namespace</code> 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>
            <code>getIterator()</code> 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>