When upgrading from a release of Zend Framework earlier than 1.9.0 to any 1.9 release, you should note the following migration notes.
For security reasons we had to turn off the default fallback mechanism of the
This means, that if the fileInfo or
magicMime extensions can not be found, the validation will
If you are in need of validation by using the HTTP fields which are provided by the user then you can turn on this feature by using the enableHeaderCheck() method.
Note: Security hint
You should note that relying on the HTTP fields, which are provided by your user, is a security risk. They can easily be changed and could allow your user to provide a malcious file.
Example #1 Allow the usage of the HTTP fields
// at initiation $valid = new Zend_File_Transfer_Adapter_Http(array('headerCheck' => true); // or afterwards $valid->enableHeaderCheck();
Prior to the 1.9 release,
the usage of the static get() method. As with
release 1.9 this method has been renamed to
filterStatic() to be more descriptive. The
old get() method is marked as deprecated.
In version 1.9 of Zend Framework, there has been a change in the way
Zend_Http_Client internally stores information about
files to be uploaded, set using the
This change was introduced in order to allow multiple files to be uploaded with the same form name, as an array of files. More information about this issue can be found in » this bug report.
Example #2 Internal storage of uploaded file information
// Upload two files with the same form element name, as an array $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 or older, the value of // the protected member $client->files is: // $client->files = array( // 'userfile' => array('file2.txt', 'application/octet-stream', 'some other data') // ); // In Zend Framework 1.9 or newer, the value of $client->files is: // $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' // ) // );
As you can see, this change permits the usage of the same form element name with more than one file - however, it introduces a subtle backwards-compatibility change and as such should be noted.
Starting from version 1.9, the protected method
_getParametersRecursive() is no longer used by
Zend_Http_Client and is deprecated. Using it will cause an
E_NOTICE message to be emitted by PHP.
If you subclass
Zend_Http_Client and call this method, you
should look into using the
Zend_Http_Client::_flattenParametersArray() static method
Again, since this _getParametersRecursive() is a protected
method, this change will only affect users who subclass
Some specialized translation methods have been deprecated because they duplicate existing behaviour. Note that the old methods will still work, but a user notice is triggered which describes the new call. The methods will be erased with 2.0. See the following list for old and new method call.
|Old call||New call|
|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)|
Prior to the 1.9 release, the menu helper
Zend_View_Helper_Navigation_Menu) did not
render sub menus correctly. When onlyActiveBranch
was TRUE and the option renderParents
FALSE, nothing would be rendered if the deepest active
page was at a depth lower than the minDepth option.
In simpler words; if minDepth was set to '1' and the active page was at one of the first level pages, nothing would be rendered, as the following example shows.
Consider the following container setup:
'Home', 'uri' => '#' ), array( 'label' => 'Products', 'uri' => '#', 'active' => true, 'pages' => array( array( 'label' => 'Server', 'uri' => '#' ), array( 'label' => 'Studio', 'uri' => '#' ) ) ), array( 'label' => 'Solutions', 'uri' => '#' ) ));
The following code is used in a view script:
navigation()->menu()->renderMenu($container, array( 'minDepth' => 1, 'onlyActiveBranch' => true, 'renderParents' => false )); ?>
Before release 1.9, the code snippet above would output nothing.
Since release 1.9, the _renderDeepestMenu() method in
Zend_View_Helper_Navigation_Menu will accept
active pages at one level below minDepth, as long as
the page has children.
The same code snippet will now output the following:
Additionally, users of the 1.9 series may be affected by other changes starting in version 1.9.7. These are all security fixes that also have potential backwards compatibility implications.
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.
In order to default to a more secure character encoding,
Zend_Filter_HtmlEntities now defaults to
UTF-8 instead of ISO-8859-1.
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.