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

<?xml version="1.0" encoding="UTF-8"?>
<!-- EN-Revision: 15234 -->
<!-- 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 role="strong">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 role="strong">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 involviert 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>