セキュリティ上の理由から、 MimeType、ExcludeMimeType、 IsCompressed および IsImage バリデータにおけるデフォルトのフォールバック機能を無効にしました。 つまり、fileInfo 拡張モジュールあるいは magicMime 拡張モジュールがなければ、 検証が常に失敗するようになるということです。

ユーザ側から渡された HTTP フィールドを使用して入力を検証する必要がある場合は、 enableHeaderCheck() メソッドを使用すればこの機能を有効にできます。

// 初期化時に
$valid = new Zend_File_Transfer_Adapter_Http(array('headerCheck' => true);

// あるいは後から
$valid->enableHeaderCheck();

Zend Framework のバージョン 1.9 では、 アップロードされるファイルに関する情報を Zend_Http_Clientが内部的に格納し、 Zend_Http_Client::setFileUpload()メソッドを用いてセットする 方法で変化がありました。

複数のファイルを同じフォーム名で ファイルの配列としてアップロードできるように この変化が取り入れられました。 この問題に関するより多くの情報は、このバグ・レポート で見つけられます。

// ファイル２つを同じフォーム要素名でファイルの配列としてアップロード
$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');

// Zend Framework の 1.8 以前では、
// protected メンバー $client->files の値はこうです:
// $client->files = array(
//     'userfile[]' => array('file2.txt',
                             'application/octet-stream',
                             'some other data')
// );

// Zend Framework の 1.9 以降では、$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'
//     )
// );

ご覧の通り、この変化は1つ以上のファイルで同じフォーム要素名を使えるようにします。 しかし、それは微妙な下位互換性変化を取り入れるので、そのように注意するべきです。

バージョン1.9から始まりますが、 protected メソッド _getParametersRecursive() はもはや Zend_Http_Client に使われず、廃止されます。 それを使うと、 E_NOTICE メッセージがPHPによって発生する原因になります。

Zend_Http_Clientをサブクラスとして、このメソッドを呼ぶなら、 その代わりに Zend_Http_Client::_flattenParametersArray() static メソッドを使用することに目を向けるべきです。

また、この_getParametersRecursiveは protected メソッドなので、 この変化はZend_Http_Clientをサブクラスとするユーザーに 影響を及ぼすだけです。

特別に用意されていたメソッドのいくつかが非推奨となります。 既存の挙動と重複しているからです。 古いメソッドも動作するにはしますが、 新しいメソッドについて説明する user notice が発生することに注意しましょう。 これらのメソッドは 2.0 で削除されます。 次の一覧で、新旧のメソッドコールを参照ください。

A slight change was made in the 1.9 series to modify the default usage of the Editor dijit to use div tags instead of a textarea tag; the latter usage has security implications, and usage of div tags is recommended by the Dojo project.

In order to still allow graceful degradation, a new degrade option was added to the view helper; this would allow developers to optionally use a textarea instead. However, this opens applications developed with that usage to XSS vectors. In 1.9.7, we have removed this option. Graceful degradation is still supported, however, via a noscript tag that embeds a textarea. This solution addressess all security concerns.

The takeaway is that if you were using the degrade flag, it will simply be ignored at this time.

よりセキュアな文字エンコードを既定値にするために、 Zend_Filter_HtmlEntities は、 ISO-8859-1 の代わりに UTF-8 を既定値にしました。

Additionally, because the actual mechanism is dealing with character encodings and not character sets, two new methods have been added, setEncoding() and getEncoding(). The previous methods setCharSet() and setCharSet() are now deprecated and proxy to the new methods. Finally, instead of using the protected members directly within the filter() method, these members are retrieved by their explicit accessors. If you were extending the filter in the past, please check your code and unit tests to ensure everything still continues to work.

Zend_Filter_StripTags contains a flag, commentsAllowed, that, in previous versions, allowed you to optionally whitelist HTML comments in HTML text filtered by the class. However, this opens code enabling the flag to XSS attacks, particularly in Internet Explorer (which allows specifying conditional functionality via HTML comments). Starting in version 1.9.7 (and backported to versions 1.8.5 and 1.7.9), the commentsAllowed flag no longer has any meaning, and all HTML comments, including those containing other HTML tags or nested commments, will be stripped from the final output of the filter.