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

    <title>Fortgeschrittene Benutzung</title>

    <para>
        Wärend die Beispiele für die Basisnutzung völlig akzeptierbar sind, in ihrem Weg Zend Framework Sessions
        zu Benutzen, ist auch die beste Praxis zu bedenken. Diese Sektion beschreibt die näheren Details von
        Session Handling und illustriert die fortgeschrittene Benutzung der Zend_Session Komponente.
    </para>

    <sect2 id="zend.session.advanced_usage.starting_a_session">

        <title>Starten einer Session</title>

        <para>
            Wenn man alle Anfragen einer Session durch Zend_Session bearbeitet haben will,
            muß die Session in der Bootstrap Datei gestartet werden:
        </para>

        <example id="zend.session.advanced_usage.starting_a_session.example">

            <title>Starten einer globalen Session</title>

            <programlisting role="php"><![CDATA[
Zend_Session::start();
]]></programlisting>

        </example>

        <para>
            Durch das Starten der Session in der Bootstrap Datei verhindert man das die Session gestartet werden
            könnte nachdem die Header an den Browser gesendet wurde, was zu einer Ausnahme und möglicherweise
            zu einer fehlerhaften Seiten im Browser führen würde. Viele gehobenen Features benötigen zuerst
            <classname>Zend_Session::start()</classname>. (Mehr dazu später in den gehobenen Features)
        </para>

        <para>
            Es gibt vier Wege eine Session zustarten wenn Zend_Session verwendet wird. Zwei sind falsch.
        </para>

        <orderedlist>
            <listitem>
                <para>
                    Falsch: PHP's
                    <ulink url="http://www.php.net/manual/de/ref.session.php#ini.session.auto-start"><code>                    session.auto_start</code>
                    Einstellung</ulink> darf nicht eingeschaltet werden. Wenn keine Möglichkeit besteht
                    diese Einstellung in php.ini zu deaktivieren, und mod_php (oder ähnliches) verwendet wird,
                    und die Einstellung schon in <code>php.ini</code> aktiviert ist, kann das folgende in der
                    <code>.htaccess</code> Datei (normalerweise im HTML Dokumenten Basisverzeichnis) hinzugefügt
                    werden:
                    <programlisting role="httpd.conf"><![CDATA[
php_value session.auto_start 0
]]>
</programlisting>
                </para>
            </listitem>
            <listitem>
                <para>
                    Falsch: PHP's <ulink url="http://www.php.net/session_start"><code>session_start()</code></ulink>
                    Funktion darf nicht direkt verwendet werden. Wenn <code>session_start()</code> direkt, und
                    anschließend <classname>Zend_Session_Namespace</classname> verwendet wird, wird von
                    <classname>Zend_Session::start()</classname> eine Ausnahme geworfen ("session has already been started").
                    Wenn <classname>Zend_Session::start()</classname> ausgerufen wird, nachdem
                    <classname>Zend_Session_Namespace</classname> verwendet wird oder <classname>Zend_Session::start()</classname>
                    explizit verwendet wird, wird ein Fehler vom Level <code>E_NOTICE</code> erzeugt und der Aufruf
                    wird ignoriert.
                </para>
            </listitem>
            <listitem>
                <para>
                    Richtig: Verwenden von <classname>Zend_Session::start()</classname>. Wenn es gewünscht ist, das alle
                    Anfragen eine Session haben und verwenden, sollte diese Funktion sehr früh, direkt und
                    entscheidungslos in der Bootstrap Datei aufgerufen werden. Session haben einigen Overhead.
                    Wenn einige Anfragen Sessions benötigen aber andere Anfragen keine Sessions verwenden, dann:
                </para>
                <itemizedlist mark="opencircle">
                    <listitem>
                        <para>
                            Entscheidungslos, die <code>strict</code> Option auf <code>true</code> setzen durch
                            Verwendung von <classname>Zend_Session::setOptions()</classname> in der Bootstrap Datei.
                        </para>
                    </listitem>
                    <listitem>
                        <para>
                            Aufruf von <classname>Zend_Session::start()</classname> nur für die Anfragen die eine Session
                            verwenden müssen und vor jeglichen <classname>Zend_Session_Namespace</classname> initiiert werden.
                        </para>
                    </listitem>
                    <listitem>
                        <para>
                            Normales verwenden von "<code>new Zend_Session_Namespace()</code>" wo es benötigt wird,
                            aber sicherstellen das davor <classname>Zend_Session::start()</classname> ausgerufen wurde.
                        </para>
                    </listitem>
                </itemizedlist>
                <para>
                    Die Option <code>strict</code> verhindert das <code>new Zend_Session_Namespace()</code>
                    automatisch eine Session startet und dabei <classname>Zend_Session::start()</classname> verwendet.
                    Deshalb hilft diese Option Anwendungs Entwicklern, sich für ein Design entscheiden
                    zu können welches verhindert das für bestimmte Anfragen Sessions verwendet werden, da es eine
                    Ausnahme verursachen würde wenn <classname>Zend_Session_Namespace</classname> instanziiert wird,
                    bevor <classname>Zend_Session::start()</classname> aufgerufen wird. Entwickler sollten vorsichtig
                    entscheiden welchen Einfluß die Verwendung von <classname>Zend_Session::setOptions()</classname> hat,
                    da diese Optionen globale Seiteneffekte hat, in Folge der Korrespondenz der darunterliegenden
                    Optionen für ext/session.
                </para>
            </listitem>
            <listitem>
                <para>
                    Richtig: Einfach <code>new Zend_Session_Namespace()</code> instanzieren wo dies auch immer
                    notwendig ist, und die darunterliegende PHP Session wird automatisch gestartet. Das bietet
                    eine extrem simple Handhabung die in den meisten Situationen gut funktioniert. Trotzdem ist man
                    dann dafür verantwortlich darauf zu schauen das das erste <code>new Zend_Session_Namespace()</code>
                    passiert <emphasis>bevor</emphasis> irgendeine Ausgabe (z.B.
                    <ulink url="http://www.php.net/headers_sent">HTTP headers</ulink> ) von PHP an den Client
                    gesendet wird, wenn standardmäßige, Cookie-basierte Sessions verwendet werden (sehr
                    empfehlenswert). Siehe <xref linkend="zend.session.global_session_management.headers_sent" />
                    für weitere Informationen.
                </para>
            </listitem>
        </orderedlist>

    </sect2>

    <sect2 id="zend.session.advanced_usage.locking">

        <title>Gesperrte Session Namensräume</title>

        <para>
            Session Namensräume können gesperrt werden um weitere Veränderungen der Daten in diesem Namensraum
            zu verhindern. Die Verwendung von <code>lock()</code> macht einen speziellen
            Namensraum nur-lesbar, <code>unLock()</code> macht einen nur-lesbaren Namensraum les- und schreibbar,
            und <code>isLocked()</code> prüft ob ein Namensraum vorher gesperrt wurde. Sperren sind flüchtig und
            bestehen nicht von einer Anfrage zur nächsten. Die Sperre des Namensraumes hat keinen Effekt auf
            Setz-Methoden von Objekten welche im Namensraum gespeichert sind, aber sie verhindert die Verwendung
            der Setz-Methoden des Namensraumes welche das gespeicherte Objekt direkt im Namensraum löschen oder
            ersetzen. Gleichwohl verhindert das Sperren von <classname>Zend_Session_Namespace</classname> Instanzen nicht
            die Verwendung von symbolischen Tabellen-Aliasen auf die gleichen Daten (siehe
            <ulink url="http://www.php.net/references">PHP references</ulink>).
        </para>

        <example id="zend.session.advanced_usage.locking.example.basic">

            <title>Sperren von Session Namensräumen</title>
            <programlisting role="php"><![CDATA[
$userProfileNamespace = new Zend_Session_Namespace('userProfileNamespace');

// marking session as read only locked
$userProfileNamespace->lock();

// unlocking read-only lock
if ($userProfileNamespace->isLocked()) {
    $userProfileNamespace->unLock();
}
]]></programlisting>

        </example>

    </sect2>

    <sect2 id="zend.session.advanced_usage.expiration">

        <title>Verfall von Namensräumen</title>

        <para>
            Limits können plaziert werden an der Lebensdauer von beidem, Namensräumen und individuellen Schlüsseln
            in Namensräumen. Normale Anwendungsfälle beinhalten das durchlaufen von temporären Informationen zwischen
            Anfragen, und das vermindern der Aufdeckung von vielfältigen Sicherheitsrisiken durch das Entfernen des
            Zugangs zu potentiell sensitiven Informationen, manchmal nachdem Authentifizierung stettgefunden hat.
            Das Ende kann entweder auf abgelaufenen Sekunden oder der Anzahl von "Sprüngen" basieren, wobei ein Sprung
            für jede folgende Anfrage stattfindet.
        </para>

        <example id="zend.session.advanced_usage.expiration.example">

            <title>Beispiel für den Verfall</title>

            <programlisting role="php"><![CDATA[
$s = new Zend_Session_Namespace('expireAll');
$s->a = 'Apfel';
$s->p = 'Pfirsich';
$s->o = 'Orange';

$s->setExpirationSeconds(5, 'a'); // Der Schlüssel "a" läuft in 5 Sekunden ab

// Der komplette Namensraum läuft in 5 "Sprüngen"
$s->setExpirationHops(5);

$s->setExpirationSeconds(60);
// Der "expireAll" Namensraum wird als "abgelaufen" markiert
// sobald der erste Aufruf empfangen wurde und 60 Sekunden
// vergangen sind, oder in 5 Sprüngen, was auch immer zuerst stattfindet
]]></programlisting>

        </example>

        <para>
            Wenn mit Daten einer Session gearbeitet wird, die in der aktuellen Anfrage ablaufen, sollte Vorsicht
            beim Empfangen dieser Daten gehalten werden. Auch wenn diese Daten durch Referenz zurückgegeben werden,
            wird die Änderung derselben, diese Daten nicht über diese Abfrage hinweg gültig machen. Um die
            Zeit für das Ablaufen zu "resetieren", müssen die Daten in eine temporäre Variable geholt werden,
            diese im Namensraum entfernt und anschliessend der entsprechende Schlüssel wieder gesetzt werden.
        </para>

    </sect2>

    <sect2 id="zend.session.advanced_usage.controllers">

        <title>Kapseln von Sessions und Kontroller</title>

        <para>
            Namensräume können auch verwendet werden um den Zugriff auf Sessions durch Kontroller zu seperieren
            um Variablen vor Kontaminierung zu schützen. Zum Beispiel könnte ein Authentifizierungs Kontroller seine
            Session Daten von allen anderen Kontrollern separat halten um notwendigen Sicherheiten zu entsprechen.
        </para>

        <example id="zend.session.advanced_usage.controllers.example">

            <title>Session Namensräume für Kontroller mit automatischem Verfall</title>

            <para>
                Der folgende Code ist Teil eines Kontrollers der die Test Frage anzeigt und eine boolsche Variable
                initialisiert die anzeigt ob eine geschickte Antwort zur Test Frage akzeptiert werden sollte oder
                nicht. In diesem Fall wird dem Benutzer der Anwendung 300 Sekunden Zeit gegeben die angezeigte
                Frage zu beantworten.
            </para>

            <programlisting role="php"><![CDATA[
// ...
// Im Frage-View Kontroller
$testSpace = new Zend_Session_Namespace('testSpace');
$testSpace->setExpirationSeconds(300, 'accept_answer');
// Nur diese Variable ablaufen lassen
$testSpace->accept_answer = true;
//...
]]></programlisting>

            <para>
                Danach bestimmt der Kontroller der die Antworten für die Test Fragen bearbeitet ob eine
                Antwort akzeptiert wird oder nach basierend darauf ob der Benutzer die Antwort in der erlaubten
                Zeit übermittelt hat:
            </para>

            <programlisting role="php"><![CDATA[
// ...
// Im Frage-Prozess Kontroller
 $testSpace = new Zend_Session_Namespace('testSpace');
 if ($testSpace->accept_answer === true) {
     // innerhalb der Zeit
 }
 else {
     // nicht innerhalb der Zeit
 }
// ...
]]></programlisting>
        </example>

    </sect2>

    <sect2 id="zend.session.advanced_usage.single_instance">

        <title>Mehrfache Instanzen pro Namensraum verhindern</title>

        <para>
            Obwohl <link linkend="zend.session.advanced_usage.locking">session locking</link> einen guten Grad von
            Schutz gegen unerlaubte Verwendung von Session Daten in einem Namensraum bietet, bietet
            <classname>Zend_Session_Namespace</classname> auch die Fähigkeit die Erzeugung von mehreren Instanzen zu verhindern
            die zu einem einzelnen Namensraum korrespondieren.
        </para>

        <para>
            Um dieses Verhalten einzuschalten, muß <code>true</code> als zweites Argument im Konstruktor angegeben
            werden wenn die letzte erlaubt Instanz von <classname>Zend_Session_Namespace</classname> erzeugt wurde. Jeder
            weitere Versuch den selben Namensraum zu instanzieren wird in einer geworfenen Ausnahme resultieren.
        </para>

        <example id="zend.session.advanced_usage.single_instance.example">

            <title>Zugriff auf Session Namensräume auf eine einzelne Instanz limitieren</title>

            <programlisting role="php"><![CDATA[
// Eine Instanz eines Namensraumes erstellen
$authSpaceAccessor1 = new Zend_Session_Namespace('Zend_Auth');

// Eine weitere Instanz des selben Namensraumes erstellen,
// aber weitere Instanzen verbieten
$authSpaceAccessor2 = new Zend_Session_Namespace('Zend_Auth', true);

// Eine Referenz erstellen ist immer noch möglich
$authSpaceAccessor3 = $authSpaceAccessor2;

$authSpaceAccessor1->foo = 'bar';

assert($authSpaceAccessor2->foo, 'bar');

try {
    $aNamespaceObject = new Zend_Session_Namespace('Zend_Auth');
} catch (Zend_Session_Exception $e) {
    echo 'Dieser Namensraum kann nicht instanziert werden da ' .
         '$authSpaceAccessor2 erstellt wurde\n';
}
]]></programlisting>

        </example>

        <para>
            Der zweite Parameter oben im Konstruktor sagt <classname>Zend_Session_Namespace</classname> das alle zukünftigen
            Instanzen  mit dem <classname>Zend_Auth</classname> Namensraum nicht erlaubt sind. Der Versuch solche Instanzen zu erstellen
            verursacht eine Ausnahme die vom Konstruktor geworfen wird. Der Entwickler wird darauf aufmerksam gemacht
            eine Referenz zu einer Instanz des Objektes irgendwo zu speichern (<code>$authSpaceAccessor1</code>,
            <code>$authSpaceAccessor2</code>, oder <code>$authSpaceAccessor3</code> im obigen Beispiel), wenn
            der Zugriff auf den Namensraum der Session zu einer späteren Zeit wärend des selben Requests benötigt
            wird. Zum Beispiel, könnte ein Entwickler die referenz in einer statischen Variable speichern, die
            Referenz zu einer <ulink url="http://www.martinfowler.com/eaaCatalog/registry.html">Registry</ulink>
            hinzufügen (siehe <xref linkend="zend.registry" />), oder diese andernfalls für andere Methoden
            verfügbar zu machen die Zugriff auf den Namensraum der Session benötigen.
        </para>

    </sect2>

    <sect2 id="zend.session.advanced_usage.arrays">

        <title>Arbeiten mit Arrays</title>

        <para>
            Durch die Vergangenheit der Implmentationen der Magischen Methoden in PHP, wird das Ändern von Arrays
            innerhalb eines Namensraumes nicht unter PHP Versionen vor 5.2.1 funktionieren. Wenn nur mit PHP 5.2.1
            oder neuer gearbeitet wird, kann <link
            linkend="zend.session.advanced_usage.objects">zum nächsten Kapitel gesprungen</link> werden.
        </para>

        <example id="zend.session.advanced_usage.arrays.example.modifying">

            <title>Array Daten innerhalb eines Session Namensraumes verändern</title>

            <para>
                Das folgende illustriert wie das Problem reproduziert werden kann:
            </para>

            <programlisting role="php"><![CDATA[
$sessionNamespace = new Zend_Session_Namespace();
$sessionNamespace->array = array();
// wird nicht wie gewünscht funktionieren vor PHP 5.2.1
$sessionNamespace->array['testKey'] = 1;
echo $sessionNamespace->array['testKey'];
]]></programlisting>

        </example>

        <example id="zend.session.advanced_usage.arrays.example.building_prior">

            <title>Arrays erstellen bevor es Session Speicher gab</title>

            <para>
                Wenn möglich, sollte das Problem vermieden werden indem Array nur dann im Session Namensraum
                gespeichert werden nachdem alle gewünschten Arraywerte gesetzt wurden.
            </para>

            <programlisting role="php"><![CDATA[
$sessionNamespace = new Zend_Session_Namespace('Foo');
$sessionNamespace->array = array('a', 'b', 'c');
]]></programlisting>

        </example>

        <para>
            Wenn eine betroffene Version von PHP verwendet wird and ein Array modifiziert werden soll nachdem es mit
            einem Schlüssel für den Session Namensraum verbunden wurde, kann einer oder beide der folgenden
            Workarounds verwendet werden.
        </para>

        <example id="zend.session.advanced_usage.arrays.example.workaround.reassign">

            <title>Workaround: Ein geändertes Array neu Verbinden</title>

            <para>
                Im folgenden Code wird eine Kopie des gespeicherten Array erstellt, geändert und wieder dem
                Platz von dem die Kopie erstellt wurde zugeordnet wobei das originale Array überschrieben wird.
            </para>

            <programlisting role="php"><![CDATA[
$sessionNamespace = new Zend_Session_Namespace();

// Das ursprüngliche Array hinzufügen
$sessionNamespace->array = array('tree' => 'apple');

// Eine Kopie des Arrays erstellen
$tmp = $sessionNamespace->array;

// Die Kopie des Arrays ändern
$tmp['fruit'] = 'peach';

// Die Kopie des Arrays wieder mit dem Namensraum der Session verknüpfen
$sessionNamespace->array = $tmp;

echo $sessionNamespace->array['fruit']; // gibt "peach" aus
]]></programlisting>

        </example>

        <example id="zend.session.advanced_usage.arrays.example.workaround.reference">

            <title>Workaround: Array das Referenz enthält speichern</title>

            <para>
                Alternativ, kann ein Array gespeichert werden das eine Referenz zum gewünschten Array enthält,
                die auf dieses dann indirekt zugegriffen werden.
            </para>

            <programlisting role="php"><![CDATA[
$myNamespace = new Zend_Session_Namespace('myNamespace');
$a = array(1, 2, 3);
$myNamespace->someArray = array( &$a );
$a['foo'] = 'bar';
echo $myNamespace->someArray['foo']; // gibt "bar" aus
]]></programlisting>

        </example>

    </sect2>

    <sect2 id="zend.session.advanced_usage.objects">

        <title>Sessions mit Objekten verwenden</title>

        <para>
             Wenn Objekte in einer PHP Session fixiert werden sollen, muß bedacht werden das diese für das Speichern
             <ulink url="http://www.php.net/manual/de/language.oop.serialization.php">serialisiert</ulink> werden.
             Deshalb muß jedes Objekt das in einer PHP Session verewigt wurde deserialisiert werden nachdem es vom
             Speicher empfangen wurde. Das impliziert das der Entwickler sicherstellen muß das die Klassen für das
             verewigte Objekt definiert werden müssen befor das Objekt vom Session Speicher deserialisiert wird.
             Wenn die Klasse eines unserialisierten Objektes nicht definiert wurde, wird es eine Instand von
             <code>stdClass</code>.
        </para>

    </sect2>

    <sect2 id="zend.session.advanced_usage.testing">

        <title>Verwenden von Sessions mit Unit Tests</title>

        <para>
            Zend Framework vertraut auf PHPUnit um das Testen von sich selbst zu ermöglichen. Viele
            Entwickler erweitern die existierende Sammlung von Unit Tests um den Code in deren Anwendungen
            anzudecken. Die Ausnahme "<emphasis>Zend_Session ist aktuell als nur-lesbar markiert</emphasis>"
            wird geworfen wärend Unit Tests durchgeführt werden, wenn irgendeine schreibende Methode verwendet wird
            nachdem Ende der Session. Trotzdem benötigen Unit Tests die Zend_Session verwenden besondere Aufmerksamkeit
            weil das Schließen (<classname>Zend_Session::writeClose()</classname>) oder Zerstören einer Session
            (<classname>Zend_Session::destroy()</classname>) weitere Änderungen oder Rücknahmen von Schlüsseln in jeder
            Instanz von <classname>Zend_Session_Namespace</classname> verhindert. Dieses Verhalten ist ein direktes Resultat
            des darunterliegenden ext/session Mechanismus und PHP's <code>session_destroy()</code> und
            <code>session_write_close()</code> welche keinen "rückgängig machen" Mechanismus unterstützen um
            Setup/Teardown innerhalb der Unit Tests zu unterstützen.
        </para>

        <para>
            Um das Umzuarbeiten, siehe den Unit Test <code>testSetExpirationSeconds()</code> in
            <code>SessionTest.php</code> und <code>SessionTestHelper.php</code>, beide im
            <code>tests/Zend/Session</code> Verzeichnis, welche PHP's <code>exec()</code> verwenden um einen
            eigenständigen Prozess zu starten. Der neue Prozess simuliert eine zweite Anfrage eines Browsers,
            viel genauer. Der separate Prozess beginnt mit einer "reinen" Session, genauso wie jede PHP Skript
            Ausführung für eine web Anfrage. Auch jede Änderung in <code>$_SESSION[]</code> welche im
            aufrufenden Prozess gemacht wurde, ist im Kind-Prozess verfügbar, ermöglicht wenn der Elternprozess
            die Session beendet hat, bevor <code>exec()</code> verwendet wird.
        </para>

        <example id="zend.session.advanced_usage.testing.example">

            <title>PHPUnit Test Code der auf Zend_Session beruht</title>

            <programlisting role="php"><![CDATA[
// testen von setExpirationSeconds()
$script = 'SessionTestHelper.php';
$s = new Zend_Session_Namespace('space');
$s->a = 'apple';
$s->o = 'orange';
$s->setExpirationSeconds(5);

Zend_Session::regenerateId();
$id = Zend_Session::getId();
// Session freigeben damit der untere Prozess Sie verwenden kann
session_write_close();
sleep(4); // nicht lange genug damit die Dinge ablaufen
exec($script . "expireAll $id expireAll", $result);
$result = $this->sortResult($result);
$expect = ';a === apfel;o === orange;p === pfirsich';
$this->assertTrue($result === $expect,
    "Iterierung durch standard Zend_Session Namensraum fehlgeschlagen; " .
    "erwartet result === '$expect', aber '$result' bekommen");
sleep(2); // lange genug damit die Dinge ablaufen (insgesamt 6 Sekunden
          // warten, aber nach 5 Sekunden abgelaufen)
exec($script . "expireAll $id expireAll", $result);
$result = array_pop($result);
$this->assertTrue($result === '',
    "Iterierung durch standard Zend_Session Namensraum fehlgeschlagen; " .
    "erwartet result === '', aber '$result' bekommen)");
session_start(); // wiederherstellen der vorher eingefrorenen Session

// Das könnte in einen separaten Test abgeteilt werden, aber aktuell, wenn
// irgendwas vom darüberleigenden Test den darunterliegenden Test
// kontaminiert, ist das auch ein Fehler den wir wissen wollen.
$s = new Zend_Session_Namespace('expireGuava');
$s->setExpirationSeconds(5, 'g'); // Versuch nur einen Schlüssel im
                                  // Namensraum ablaufen zu lassen
$s->g = 'guava';
$s->p = 'peach';
$s->p = 'plum';

// Session auflösen damit der untere Prozess sie verwenden kann
session_write_close();
sleep(6); // Nicht lange genug damit die Dinge ablaufen können
exec($script . "expireAll $id expireGuava", $result);
$result = $this->sortResult($result);
session_start(); // Die bestimmte Session wiederherstellen
$this->assertTrue($result === ';p === plum',
    "Iterierung durch benannte Zend_Session Namensräume " .
    "fehlgeschlaten (result=$result)");
]]></programlisting>
        </example>

    </sect2>

</sect1>
