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.

// Bei der Initiierung
$valid = new Zend_File_Transfer_Adapter_Http(array('headerCheck' => true);

// oder im Nachhinein
$valid->enableHeaderCheck();

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.

// Zwei Dateien mit dem gleichen Namen des Formularelements als Array hochladen
$client = new Zend_Http_Client();
$client->setFileUpload('file1.txt',
                       'userfile[]',
                       'some raw data',
                       'text/plain');
$client->setFileUpload('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.

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.

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.

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.

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.

Zend_Filter_StripTags enthielt in voehergehenden Versionen ein commentsAllowed Flag, welches es erlaubt hat HTML Kommentare in von dieser Klasse gefiltertem HTML Text als erlaubt zu markieren. Aber das öffnet den Weg für XSS Attacken, speziell im Internet Explorer (der es erlaubt konditionelle Funktionalität über HTML Kommentare zu spezifizieren). Beginnend mit Version 1.9.7 (und retour mit den Versionen 1.8.5 und 1.7.9), hat das commentsAllowed Flag keine Bedeutung meht, und alle HTML Kommentare, inklusive denen die andere HTML Tags oder untergeordnete Kommentare enthalten, werden von der endgültigen Aufgabe des Filters entfernt.