Zend Framework 1.7Wenn man von einem älteren Release auf Zend Framework 1.7 oder höher hochrüstet sollte man die folgenden Migrations Hinweise beachten. Zend_ControllerÄnderungen im Dispatcher InterfaceBenutzer haben uns darauf aufmerksam gemacht das Zend_Controller_Action_Helper_ViewRenderer Methoden auf der abstrakten Dispatcher Klasse verwendet hat die nicht im Dispatcher Interface waren. Die folgenden Methoden wurden hinzugefügt um sicherzustellen das eigene Dispatcher weiterhin mit den ausgelieferten Implementierungen funktionieren:
Zend_File_TransferÄnderungen bei der Verwendung von Filtern und PrüfungenWie von Benutzern erwähnt, arbeiteten die Prüfungen von Zend_File_Transfer nicht in Verbindung mit Zend_Config zusammen, durch den Fakt das Sie keine benannten Arrays verwendet haben. Deswegen wurden alle Filter und Prüfungen für Zend_File_Transfer überarbeitet. Wärend die alten Signaturen weiterhin funktionieren, wurden sie als veraltet markiert, und werfen eine PHP Notiz mit der Aufforderung das zu beheben. Die folgende Liste zeigt die Änderungen und was für die richtige Verwendung der Parameter getan werden muß. Filter: Rename
Example #1 Änderungen für den Rename Filter von 1.6 zu 1.7
Prüfung: Count
Example #2 Änderungen für die Count Prüfung von 1.6 zu 1.7
Prüfung: Extension
Example #3 Änderungen für die Extension Prüfung von 1.6 zu 1.7
Prüfung: FilesSize
Zustätzlich wurde die Signatur der useByteString() Methode geändert. Sie kann nur verwendet werden um zu testen ob die Prüfung ByteStrings in den erzeugten Meldungen verwendet oder ncht. Um den Wert dieses Flags zu setzen muß die setUseByteString() Methode verwendet werden. Example #4 Änderungen für die FilesSize Prüfung von 1.6 zu 1.7
Prüfung: Hash
Example #5 Änderungen für die Hash Prüfung von 1.6 zu 1.7
Prüfung: ImageSize
Example #6 Änderungen für die ImageSize Prüfung von 1.6 zu 1.7
Prüfung: Size
Example #7 Änderungen für die Size Prüfung von 1.6 zu 1.7
Zend_LocaleÄnderungen bei der Verwendung von isLocale()Bezugnehmend auf den Codingstandard mußte isLocale() so geändert werden das es ein Boolean zurückgibt. In vorhergehenden Releases wurde im Erfolgsfall ein String zurückgegeben. Für das Release 1.7 wurde ein Kompatibilitätsmodus hinzugefügt der es erlaubt das alte Verhalten, das ein String zurückgegeben wird, zu verwenden, aber das triggert auch eine User Warning die darauf hinweist das man auf das neue Verhalten wechseln sollte. Das Rerouting welches das alte Verhalten von isLocale() durchgeführt hätte ist nicht länger notwendig, da alle I18n Komponenten jetzt das Rerouting selbst durchführen. Um die Skripte auf die neue API zu migrieren muß die Methode einfach wie anbei gezeigt verwendet werden. Example #8 Wie man isLocale() von 1.6 nach 1.7 ändern muß
Es ist zu beachten das man den zweiten Parameter verwendet kann um zu sehen ob das Gebietsschema richtig ist ohne das ein Rerouting durchgeführt wird.
Änderungen bei der Verwendung von getDefault()Die Bedeutung der getDefault() Methode wurde verändert durch den Fakt das Framework-weite Gebietsschemata integriert wurden welche mit setDefault() gesetzt werden können. Deswegen gibe es nicht mehr die Kette der Gebietsschemata zurück sondern nur die gesetzten Framework-weiten Gebietsschemata. Um die eigenen Skripte auf die neue API zu migrieren, muß einfach die Methode wie unten gezeigt verwendet werden. Example #9 Wie man getDefault() von 1.6 auf 1.7 ändert
Es ist zu beachten das der zweite Parameter der alten getDefault() Implementation nicht mehr vorhanden ist, aber die zurückgegebenen Werte die gleichen sind.
Zend_TranslateSetzen von SprachenWenn man die automatische Erkennung von Sprachen verwendet, oder Sprachen manuell auf Zend_Translate setzt kann es sein das man von Zeit zu Zeit eine Notiz geworfen bekommen die über nicht hinzugefügte oder leere Übersetzungen schreibt. In einigen vorhergehenden Releases wurde in einigen Fällen auch eine Exception geworfen. Der Grund ist, das wenn ein Benutzer eine nicht existierende Sprache anfragt, man einfach keinen Weg hat um festzustellen was falsch ist. Deswegen haben wir diese Notizen hinzugefügt die einem in den eigenen Logs zeigen das der Benutzer eine Sprache angefragt hat die man nicht unterstützt. Es ist zu beachten das der Code, selbst wenn eine Notiz getriggert wird, weiterhin ohne Probleme arbeitet. Aber wenn man einen eigenen Fehler oder Exception Handler, wie XDebug, verwendet wird man alle Notizen zurückerhalten, selbst wenn man das nicht gewollt hat. Das ist der Fall, weil diese Handler alle Einstellungen von PHP selbst überschreiben. Um diese Notizen wegzubekommen kann man einfach die neue Option 'disableNotices' auf TRUE setzen. Der Standardwert ist FALSE. Example #10 Setzen von Sprachen ohne das man Notizen erhält Nehmen wir an das wir 'en' vorhanden haben und unser Benutzer 'fr' anfragt was nicht in unserem Portfolio der übersetzten Sprachen ist.
In diesem Fall werden wir eine Notiz darüber erhalten das die Sprache 'fr' nicht vorhanden ist. Durch das einfache Hinzufügen der Option wird die Notiz abgeschaltet.
Zend_View
Vor dem 1.7.5 Release wurde das Zend Framework Team darauf aufmerksam gemacht das eine potentielle Local File Inclusion (LFI) Schwäche in der Zend_View::render() Methode existiert. Vor 1.7.5, erlaubte die Methode standardmäßig, die Fähigkeit View Skripte zu spezifizieren die Schreibweisen für Eltern-Verzeichnisse enthalten (z.B. "../" oder "..\"). Das öffnet die Möglichkeit für eine LFI Attacke wenn ungefilterte Benutzereingaben an die render() Methode übergeben werden:
Zend_View wirft jetzt standardmäßig eine Ausnahme wenn so ein View Skript angefragt wird. Ausschalten des LFI Schutzes für die render() MethodeDa viele Entwickler gemeldet haben das Sie so eine Schreibweise in Ihren Anwendungen verwenden die nicht das Ergebnis einer Benutzereingabe sind, wurde ein spezielles Flag erstellt um das Deaktivieren des standardmäßigen Schutzes zu erlauben. Es gibt 2 Methoden um das Durchzuführen: Indem der 'lfiProtectionOn' Schlüssel in den Konstruktor-Optionen übergeben wird, oder durch den expliziten Aufruf der setLfiProtection() Methode.
|