Previous Next

Globales Session Management

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 » üblichen Optionen, welche von ext/session unterstützt werden, durch Zend_Session::setOptions() enthält. Zum Beispiel kann, das fehlerhafte Versichern das ein sicherer save_path oder ein eindeutiger Cookiename von ext/session durch Zend_Session::setOptions() verwendet wird, zu einem Sicherheitsproblem werden.

Konfigurations Optionen

Wenn der erste Session Namensraum angefragt wird, startet Zend_Session automatisch die PHP Session, ausser er wurde bereits mit Zend_Session::start() gestartet. Die darunterliegende PHP Session verwendet die Standards von Zend_Session, ausser wenn Sie schon durch Zend_Session::setOptions() modifiziert wurde.

Um eine Konfigurations Option einer Session zu setzen, muß der Basisname (der Teil des Namens nach "session.") als Schlüssel eines Array inkludiert und an Zend_Session::setOptions() ü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 » fw-auth@lists.zend.com.

Example #1 Verwenden von Zend_Config um Zend_Session zu konfigurieren

Um diese Komponente mit Hilfe von Zend_Config_Ini zu konfigurieren, muß zuerst die Konfigurations-Option dem INI File hinzugefügt werden:

; 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 = 
; 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

Als nächstes die Konfigurationsdatei laden und dessen Array Representation Zend_Session::setOptions() übergeben:

$config = new Zend_Config_Ini('myapp.ini', 'development');

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

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.

  • boolean strict - verhindert das automatische Starten von Zend_Session wenn new Zend_Session_Namespace() verwendet wird.

  • integer remember_me_seconds - Wie lange soll das Session Id Cookie bestehen, nachdem der Benutzer Agent beendet wurde (z.B. Browser Anwendung geschlossen)

  • string save_path - Der richtige Wert ist abhängig vom System, und sollte vom Entwickler auf einen absoluten Pfad zu einem Verzeichnis bereitgestellt werden, welches durch den PHP Prozess lesbar und beschreibbar ist. Wenn kein schreibbarer Pfad gegeben ist, wird Zend_Session eine Ausnahme werden sobald Sie gestartet wird (z.B. wenn start() aufgerufen wird).

    Note: Sicherheits Risiko

    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 » Session vergiftet 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).

    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 var_dump($_SESSION) 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 save_path der Anwendung haben. Wenn der save_path erahnbar ist und der Angreifer die Kontrolle über eine der zwei Webseiten hat, kann der Angreifer den save_path 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 save_path nicht öffentlich bekanntgegeben werden, und er sollte geändert werden um dem Pfad eindeutig für jede Anwendung zu sichern.

  • string name - 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 eindeutig ist.

    Note: Sicherheits Risiko

    Wenn die php.ini Einstellung für session.name 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.

  • boolean use_only_cookies - Um zusätzliche Sicherheitsrisiken zu vermeiden, sollte der Standardwert dieser Option nicht verändert werden.

    Note: Sicherheits Risiko

    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. http://www.example.com/index.php?PHPSESSID=fixed_session_id. 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.

Fehler: Header schon gesendet

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.

  • » Puffern der Ausgabe ist oft notwendig um dieses Problem zu verhindern, und hilft bei der Steigerung der Geschwindigkeit. Zum Beispiel aktiviert "output_buffering = 65535" in der php.ini 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.

  • 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.

  • 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 destroy() einen HTTP Header um das Session Cookie auf der Seite des Clients ablaufen zu lassen. Wenn das nicht benötigt wird sollte destroy(false) verwendet werden, da die Anweisungen für das Ändern von Cookies im HTTP Header gesendet.

  • 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.

  • Jedes schließende "?>" 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.

Session Identifizierer

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 ($_SESSION) 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 regenerateId() 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.

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 regenerateId() die Daten der Session vom alten Session Id "Handle" zum neuen, weswegen keine Daten über die alte Session Id abrufbar sind.

Wann sollte regenerateId() verwendet werden: Das Hinzufügen von Zend_Session::regenerateId() 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 regenerateId() zu verwenden um eine neue Session Id zu erstellen. Wenn die rememberMe() Funktion aufgerufen wird, sollte regenerateId() nicht verwendet werden, ausser der erstere ruft den letzteren auf. Wenn sich ein Benutzer erfolgreich auf die Webseite eingeloggt hat, sollte rememberMe() statt regenerateId() verwendet werden.

Session-Entführung und Fixierung

Das Vermeiden von » Seiten übergreifenden Script (XSS) Gefährdungen hilft bei der Vorbeugung von Session Entführungen. Laut » Secunia's 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 save_path Option richtig eingestellt hat.

Nur durch das Aufrufen von Zend_Session::regenerateId(), 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ß (regenerateId()). 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 use_only_cookies = off).

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:

  • Der Angreifer initiiert eine Session auf der Webseite um eine gültige Session Id zu erhalten

  • 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

  • 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)

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.

Example #2 Session Fixierung

$defaultNamespace = new Zend_Session_Namespace();

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

>rememberMe(integer $seconds)

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. Zend_Session::rememberMe() 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 remember_me_seconds, welche durch Verwendung von Zend_Session::setOptions() 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).

forgetMe()

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

sessionExists()

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 Zend_Session und Zend_Session_Namespace Methoden.

destroy(bool $remove_cookie = true, bool $readonly = true)

Zend_Session::destroy() 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 Zend_Session_Namespace) lesbar bleibt. Es ein "Logout" fertigzustellen, muß der optionale Parameter auf true (standard) gesetzt werden um auch das Session Id Cookie des User Agents zu löschen. Der optionale $readonly Parameter entfernt die Möglichkeit neue Zend_Session_Namespace Instanzen zu erstellen und für Zend_Session in den Session Daten Speicher zu schreiben.

Wenn die Fehlermeldung "Cannot modify header information - headers already sent" erscheint, sollte entweder die Verwendung von true als Wert für das erste Argument (die Entfernung des Session Cookies anfragen) vermieden werden, oder unter Fehler: Header schon gesendet nachgesehen werden. Deswegen muß "Zend_Session::destroy(true)" entweder 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 destroy() zu Verhindern.

Note: Wirft

Standardmäßig ist $readonly aktiviert, und weitere Aktionen welche das Schreiben in den Session Daten Speicher beinhalten, werfen eine Ausnahme.

stop()

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 Zend_Session_Namespace Instanzen oder Zend_Session 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.

writeClose($readonly = true)

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

Note: Wirft

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

expireSessionCookie()

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.

setSaveHandler(Zend_Session_SaveHandler_Interface $interface)

Die meisten Entwickler werden den Standardmäßigen Speicher Handle ausreichend finden. Diese Methode bietet einen objekt-orientierten Wrapper für » session_set_save_handler().

namespaceIsset($namespace)

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

Note: Wirft

Eine Ausnahme wird geworfen wenn Zend_Session nicht als lesbar markiert ist (z.B. bevor Zend_Session gestartet wurde).

namespaceUnset($namespace)

Zend_Session::namespaceUnset($namespace) 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. namespaceUnset() 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 » Referenzen erklärt nachgesehen werden.

Note: Wirft

Eine Ausnahme wird geworfen wenn der Namensraum nicht beschreibbar ist (z.B. nach destroy()).

namespaceGet($namespace)

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

Note: Wirft

Eine Ausnahme wird geworfen wenn Zend_Session nicht als lesbar markiert ist (z.B bevor Zend_Session gestartet wurde).

getIterator()

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

Note: Wirft

Eine Ausnahme wird geworfen wenn Zend_Session nicht als lesbar markiert ist (z.B. bevor Zend_Session gestartet wurde).

Previous Next
Introduction to Zend Framework
Übersicht
Installation
Zend_Acl
Einführung
Verfeinern der Zugriffskontrolle
Fortgeschrittene Verwendung
Zend_Amf
Einführung
Zend_Amf_Server
Zend_Auth
Einführung
Datenbanktabellen Authentifizierung
Digest Authentication
HTTP Authentication Adapter
LDAP Authentifizierung
Open ID Authentifikation
Zend_Cache
Einführung
Die Theorie des Cachens
Zend_Cache Frontends
Zend_Cache Backends
Zend_Captcha
Einführung
Captcha Anwendung
Captcha Adapter
Zend_Config
Einleitung
Theory of Operation
Zend_Config_Ini
Zend_Config_Xml
Zend_Config_Writer
Zend_Config_Writer
Zend_Console_Getopt
Einführung in Getopt
Definieren von Getopt Regeln
Holen von Optionen und Argumenten
Konfigurieren von Zend_Console_Getopt
Zend_Controller
Zend_Controller Schnellstart
Zend_Controller Grundlagen
Der Front Controller
Das Request Objekt
Der Standard Router
Der Dispatcher
Action Kontroller
Action Helfer
Das Response Objekt
Plugins
Eine konventionelle modulare Verzeichnis Struktur verwenden
MVC Ausnahmen
Migration von vorhergehenden Versionen
Zend_Currency
Einführung in Zend_Currency
Arbeiten mit Währungen
Migration von vorhergehenden Versionen
Zend_Date
Einführung
Theorie der Arbeitsweise
Basis Methoden
Zend_Date API Übersicht
Erstellen von Datumswerten
Konstanten für generelle Datums Funktionen
Funktionierende Beispiele
Zend_Db
Zend_Db_Adapter
Zend_Db_Statement
Zend_Db_Profiler
Zend_Db_Select
Zend_Db_Table
Zend_Db_Table_Row
Zend_Db_Table_Rowset
Zend_Db_Table Relationships
Zend_Debug
Variablen ausgeben
Zend_Dojo
Einführung
Zend_Dojo_Data: dojo.data Envelopes
Dojo View Helfer
Dojo Form Elemente und Dekoratore
Zend_Dom
Einführung
Zend_Dom_Query
Zend_Exception
Verwenden von Ausnahmen
Zend_Feed
Einführung
Feeds importieren
Feeds von Websites abrufen
Einen RSS Feed konsumieren
Einen Atom Feed konsumieren
Einen einzelnen Atom Eintrag konsumieren
Verändern der Feed- und Eintragsstruktur
Eigene Klassen für Feeds und Einträge
Zend_File
Zend_File_Transfer
Prüfungen für Zend_File_Transfer
Filter für Zend_File_Transfer
Migration von vorhergehenden Versionen
Zend_Filter
Einführung
Standard Filter Klassen
Filter Ketten
Filter schreiben
Zend_Filter_Input
Zend_Filter_Inflector
Zend_Form
Zend_Form
Schnellstart mit Zend_Form
Erstellen von Form Elementen mit Hilfe von Zend_Form_Element
Erstellen von Form durch Verwendung von Zend_Form
Erstellen von eigenem Form Markup durch Zend_Form_Decorator
Standard Form Elemente die mit dem With Zend Framework ausgeliefert werden
Standard Form Dekoratore die mit dem Zend Framework ausgeliefert werden
Internationalisierung von Zend_Form
Fortgeschrittene Verwendung von Zend_Form
Zend_Gdata
Einführung zu Gdata
Authentifizierung mit AuthSub
Die Buchsuche Daten API verwenden
Authentifizieren mit ClientLogin
Google Kalender verwenden
Verwenden der Google Dokumente Listen Daten API
Using Google Health
Google Tabellenkalkulation verwenden
Google Apps Provisionierung verwenden
Google Base verwenden
Picasa Web Alben verwenden
Verwenden der YouTube Daten API
Gdata Ausnahmen auffangen
Zend_Http
Zend_Http_Client - Einführung
Zend_Http_Client - Fortgeschrittende Nutzung
Zend_Http_Client - Verbindungsadapter
Zend_Http_Cookie und Zend_Http_CookieJar
Zend_Http_Response
Zend_InfoCard
Einführung
Zend_Json
Einführung
Grundlegende Verwendung
JSON Objects
XML zu JSON Konvertierung
Zend_Json_Server - JSON-RPC server
Zend_Layout
Einführung
Zend_Layout Schnellstart
Zend_Layout Konfigurations Optionen
Erweiterte Verwendung von Zend_Layout
Zend_Ldap
Einleitung
Zend_Loader
Dynamisches Laden von Dateien und Klassen
Plugins laden
Zend_Locale
Einführung
Zend_Locale verwenden
Normalisierung und Lokalisierung
Arbeiten mit Daten und Zeiten
Unterstützte Gebietsschemata
Migrieren von vorhergehenden Versionen
Zend_Log
Übersicht
Writer
Formatter
Filter
Zend_Mail
Einführung
Versand über SMTP
Versand von mehreren E-Mails über eine SMTP Verbindung
Verwendung von unterschiedlichen Versandwegen
HTML E-Mail
Anhänge
Empfänger hinzufügen
Die MIME Abgrenzung kontrollieren
Zusätzliche Kopfzeilen
Zeichensätze
Kodierung
SMTP Authentifizierung
SMTP Übertragungen sichern
Lesen von Mail Nachrichten
Zend_Measure
Einführung
Erstellung einer Maßeinheit
Ausgabe von Maßeinheiten
Manipulation von Maßeinheiten
Arten von Maßeinheiten
Zend_Memory
Übersicht
Memory Manager
Memory Objekte
Zend_Mime
Zend_Mime
Zend_Mime_Message
Zend_Mime_Part
Zend_OpenId
Einführung
Zend_OpenId_Consumer Grundlagen
Zend_OpenId_Provider
Zend_Paginator
Einführung
Verwendung
Konfiguration
Advanced usage
Zend_Pdf
Einführung
Erstellen und Laden von PDF Dokumenten
Änderungen von PDF Dokumenten speichern
Dokument Seiten
Zeichnen
Dokument Informationen und Metadaten
Anwendungsbeispiel für die Zend_Pdf Komponente
Zend_ProgressBar
Zend_ProgressBar
Zend_Registry
Die Registry verwenden
Zend_Rest
Einführung
Zend_Rest_Client
Zend_Rest_Server
Zend_Search_Lucene
Überblick
Indexerstellung
Einen Index durchsuchen
Abfragesprache
Abfrage Erzeugungs API
Zeichensätze
Erweiterbarkeit
Zusammenarbeit Mit Java Lucene
Erweitert
Die besten Anwendungen
Zend_Server
Einführung
Zend_Server_Reflection
Zend_Service
Einführung
Zend_Service_Akismet
Zend_Service_Amazon
Zend_Service_Audioscrobbler
Zend_Service_Delicious
Zend_Service_Flickr
Zend_Service_Nirvanix
Zend_Service_ReCaptcha
Zend_Service_Simpy
Einführung
Zend_Service_StrikeIron
Zend_Service_StrikeIron: Mitgelieferte Services
Zend_Service_StrikeIron: Erweiterte Verwendung
Zend_Service_Technorati
Zend_Service_Twitter
Zend_Service_Yahoo
Zend_Session
Einführung
Grundsätzliche Verwendung
Fortgeschrittene Benutzung
Globales Session Management
Zend_Session_SaveHandler_DbTable
Zend_Soap
Zend_Soap_Server
Zend_Soap_Client
WSDL Zugriffsmethoden
AutoDiscovery
Zend_Test
Einführung
Zend_Test_PHPUnit
Zend_Text
Zend_Text_Figlet
Zend_Text_Table
Zend_TimeSync
Einführung
Arbeiten mit Zend_TimeSync
Zend_Translate
Einführung
Adapter für Zend_Translate
Benutzen von Übersetzungs Adaptoren
Migration von vorhergehenden Versionen
Zend_Uri
Zend_Uri
Zend_Validate
Einführung
Standard Prüfklassen
Kettenprüfungen
Schreiben von Prüfern
Zend_Version
Auslesen der Version des Zend Frameworks
Zend_View
Einführung
Controller Skripte
View Scripte
View Helfer
Zend_View_Abstract
Zend_Wildfire
Zend_Wildfire
Zend_XmlRpc
Einführung
Zend_XmlRpc_Client
Zend_XmlRpc_Server
Zend Framework Voraussetzungen
PHP Version
PHP Erweiterungen
Zend Framework Komponenten
Zend Framework Abhängigkeiten
Zend Framework Coding Standard für PHP
Übersicht
PHP Dateiformatierung
Namens Konventionen
Code Stil
Zend Framework Performance Guide
Einführung
Laden von Klassen
Internationalisierung (I18n) und Lokalisierung (L10n)
Darstellen der View
Urheberrecht Informationen