Zend Framework 1.9
Wenn man von einem Zend Framework Release vor 1.9.0 zu einem beliebigen 1.9 Release
hochrüstet sollte man die folgenden Migrations Hinweise beachten.
Zend_File_Transfer
MimeType Prüfung
Aus Sicherheitsgründen haben wir den standardmäßigen Fallback Mechanismus der
MimeType, ExcludeMimeType,
IsCompressed und IsImage Prüfungen
ausgeschaltet. Das bedeutet, wenn die fileInfo oder
magicMime Erweiterungen nicht gefunden werden können, dann
wird die Prüfung immer fehlschlagen.
Wenn es notwendig ist das man für die Prüfung die HTTP Felder
verwendet welche vom Benutzer geschickt werden, dann kann man dieses Feature
einschalten indem die enableHeaderCheck() Methode
verwendet wird.
Note: Sicherheits Hinweis
Man sollte beachten, das wenn man sich auf die HTTP Felder
verlässt, die vom Benutzer geschickt werden, das ein Sicherheits Risiko ist.
Diese können einfach geändert werden und könnten es einem Benutzer erlauben eine
schädliche Datei zu schicken.
Example #1 Die Verwendung der HTTP Felder erlauben
// Bei der Initiierung
'headerCheck'// oder im Nachhinein
Zend_Filter
Vor dem Release 1.9 erlaubte Zend_Filter die Verwendung der
statischen Methode get(). Ab dem Release 1.9 wurde diese
Methode zu filterStatic() umbenannt um besser zu beschreiben
was Sie macht. Die alte get() Methode wurde als deprecated
markiert.
Zend_Http_Client
Änderungen in der internen Speicherung der Information von hochgeladenen Dateien
In Version 1.9 vom Zend Framework gibt es eine Ändernug wie
Zend_Http_Client Informationen über hochgeladenen Dateien
intern speichert, bei denen die
Zend_Http_Client::setFileUpload() Methode verwendet wird.
Diese Änderung wurde durchgeführt um es zu erlauben mehrere Dateien mit dem
gleichen Formularnamen, als Array von Dateien, hochzuladen. Weitere Informationen
über dieses Problem können in » diesem
Fehlerreport gefunden werden.
Example #2 Interne Speicherung der Informationen von hochgeladenen Dateien
// Zwei Dateien mit dem gleichen Namen des Formularelements als Array hochladen
'file1.txt',
'userfile[]',
'some raw data',
'text/plain''file2.txt',
'userfile[]',
'some other data',
'application/octet-stream');
// In Zend Framework 1.8 oder älter, ist der Wert der geschützten
// Variable $client->files:
// $client->files = array(
// 'userfile[]' => array('file2.txt',
'application/octet-stream',
'some other data')
// );
// In Zend Framework 1.9 oder neuer, ist der Wert von $client->files:
// $client->files = array(
// array(
// 'formname' => 'userfile[]',
// 'filename' => 'file1.txt,
// 'ctype' => 'text/plain',
// 'data' => 'some raw data'
// ),
// array(
// 'formname' => 'userfile[]',
// 'filename' => 'file2.txt',
// 'formname' => 'application/octet-stream',
// 'formname' => 'some other data'
// )
// );
Wie man sieht gestattet diese Änderung die Verwendung des gleichen Namens für das
Formularelement mit mehr als einer Datei - trotzdem führt dies zu einer subtilen
Änderung der Rückwärtskompatibilität und sollte erwähnt werden.
Zend_Http_Client::_getParametersRecursive() sollte nicht mehr eingesetzt werden
Beginnend mit Version 1.9, wird die geschützte Methode
_getParametersRecursive() nicht mehr von
Zend_Http_Client verwendet und ist abgelehnt (deprecated).
Ihre Verwendung führt zu einer E_NOTICE Nachricht die von
PHP kommt.
Wenn man Zend_Http_Client erweitert und diese Methode
aufrufr, sollte man sehen das man stattdessen die statische Methode
Zend_Http_Client::_flattenParametersArray() verwendet.
Nochmals, da _getParametersRecursive() eine geschützte
Methode ist, sind nur Benutzer betroffen die Zend_Http_Client
erweitert haben.
Zend_Locale
Abgelaufene Methoden
Einige spezialisiertere Übersetzungsmethoden stehen nicht mehr zur Verfügung weil
Sie bestehende Verhaltensweisen duplizieren. Beachten Sie das die alten Methoden
weiterhin funktionieren, aber eine Benutzer Notiz geworfen wird, die den neuen
Aufruf beschreibt. Diese Methoden werden mit 2.0 entfernt. Die folgende Liste zeigt
die alten und neuen Methodenaufrufe.
List der Methodenaufrufe
Alter Aufruf |
Neuer Aufruf |
getLanguageTranslationList($locale)
|
getTranslationList('language', $locale)
|
getScriptTranslationList($locale)
|
getTranslationList('script', $locale)
|
getCountryTranslationList($locale)
|
getTranslationList('territory', $locale, 2)
|
getTerritoryTranslationList($locale)
|
getTranslationList('territory', $locale, 1)
|
getLanguageTranslation($value, $locale)
|
getTranslation($value, 'language', $locale)
|
getScriptTranslation($value, $locale)
|
getTranslation($value, 'script', $locale)
|
getCountryTranslation($value, $locale)
|
getTranslation($value, 'country', $locale)
|
getTerritoryTranslation($value, $locale)
|
getTranslation($value, 'territory',
$locale)
|
Zend_View_Helper_Navigation
Vor dem Release 1.9 hat der Menü Helfer
(Zend_View_Helper_Navigation_Menu) Untermenüs nicht richtig
dargestellt. Wenn onlyActiveBranch TRUE war
und die Option renderParents FALSE wurde
nichts dargestellt wenn die tiefste aktive Seite auf einer geringeren Tiele als die
minDepth Option war.
In einfacheren Worten; Wenn minDepth auf '1' gesetzt war und
die aktive Seite eine der Seiten am Anfangs-Level, wurde nichts dargestellt wie das
folgende Beispiel zeigt.
Das folgende Container Setup wird angenommen:
span style="color: #ff0000;">'label' => 'Home',
'uri' => '#''label' => 'Products',
'uri' => '#',
'active''pages''label' => 'Server',
'uri' => '#''label' => 'Studio',
'uri' => '#''label' => 'Solutions',
'uri' => '#'
)
));
Der folgende Code wird in einem View Script verwendet:
span style="color: #ff0000;">'minDepth' => 1,
'onlyActiveBranch''renderParents'
Vor dem Release 1.9 würde der obige Codeabschnitt nichts ausgeben.
Seit dem Release 1.9 akzeptiert die _renderDeepestMenu()
Methode in Zend_View_Helper_Navigation_Menu aktive Seiten die ein
Level unter minDepth sind, solange diese Seite Kinder hat.
Der gleiche Codeabschnitt zeigt jetzt die folgende Ausgabe:
<ul class="navigation">
<li>
<a href="#">Server</a>
</li>
<li>
<a href="#">Studio</a>
</li>
</ul>
Sicherheitsfixes ab 1.9.7
Zusätzlich können Benutzer der Serie 1.9 von anderen Änderungen beginnend in Version
1.9.7 betroffen sein. Das sind alles Sicherheitsbehebungen welche auch potentiell
Probleme mit Rückwärtskompatibilität haben können.
Zend_Dojo_View_Helper_Editor
Eine kleine Änderung wurde in der Serie 1.9 gemacht um die Standardverwendung des
dijit Editors zu modifizieren um div Tags statt einem
textarea Tag zu verwenden; die letztere Verwendung bringt » Sicherheits
Probleme mit sich, und die Verwendung von div Tags
wird vom Dojo Projekt empfohlen.
Um trotzdem eine erfolgreiche Degration zu erlauben, wurde dem View Helper eine neue
Option degrade hinzugefügt; diese erlaubt es Entwicklern statt
dessen optional ein textarea zu verwenden. Trotzdem öffnet dies
Anwendungen die damit entwickelt wurden XSS Vektoren. In 1.9.7
wurde diese Option entfernt. Die erfolgreiche Degration wird trotzdem, über das
noscript Tag unterstützt welches eine textarea
enthält. Diese Lösung adressiert Sicherheitsbedenken.
Die Folgerung ist, das wenn man das degrade Flag verwendet,
dieses ab diesem Zeitpunkt einfach ignoriert wird.
Zend_Filter_HtmlEntities
Um zu einem höheren Sicherheitsstandard für die Zeichenkodierung zu kommen, ist der
Standardwert von Zend_Filter_HtmlEntities jetzt
UTF-8 statt ISO-8859-1.
Zusätzlich, weil der aktuelle Mechanismus mit Zeichenkodierung handelt und nicht mit
Zeichensets, wurden zwei Methoden hinzugefügt.
setEncoding() und getEncoding().
Die vorhergehenden Methoden setCharSet() und
setCharSet() sind jetzt deprecated und verweisen auf die
neuen Methoden. Letztendlich, statt die geschützten Mitglieder in der
filter() Methode direkt zu verwenden, werden Sie durch Ihre
expliziten Zugriffsmethoden empfangen. Wenn man den Filter in der Vergangenheit
erweitert hat, sollte man seinen Code und seine Unittests prüfen um sicherzustellen
das weiterhin alles funktioniert.
|
|