Por razones de seguridad hemos tenido que desactivar el mecanismo de reserva por defecto de los validadores MimeType, ExcludeMimeType, IsCompressed e IsImage. Esto significa que si no se encuentran las extensiones fileInfo o magicMime, la validación siempre fallará.

Si necesita realizar la validación usando los campos HTTP proporcionados por el usuario, puede activar esta funcionalidad mediante el método enableHeaderCheck().

	Consejo de seguridad
	Debe tener en cuenta que confiar en los campos HTTP proporcionados por su usuario supone un riesgo de seguridad. Estos pueden modificarse fácilmente y podrían permitir a su usuario proporcionar un archivo malicioso.

// at initiation
$valid = new Zend_File_Transfer_Adapter_Http(array('headerCheck' => true);

// or afterwards
$valid->enableHeaderCheck();

En la versión 1.9 de Zend Framework, se ha producido un cambio en la forma en que Zend_Http_Client almacena internamente la información sobre los archivos que se van a subir, establecida mediante el método Zend_Http_Client::setFileUpload().

Este cambio se introdujo para permitir la subida de múltiples archivos con el mismo nombre de formulario, como un array de archivos. Puede encontrar más información sobre este asunto en este informe de error.

// 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'
//     )
// );

Como puede ver, este cambio permite el uso del mismo nombre de elemento de formulario con más de un archivo; sin embargo, introduce un cambio sutil de compatibilidad con versiones anteriores que conviene tener en cuenta.

A partir de la versión 1.9, el método protegido _getParametersRecursive() ya no es utilizado por Zend_Http_Client y queda obsoleto. Su uso provocará que PHP emita un mensaje E_NOTICE.

Si extiende Zend_Http_Client y llama a este método, debería considerar el uso del método estático Zend_Http_Client::_flattenParametersArray() en su lugar.

De nuevo, dado que _getParametersRecursive() es un método protegido, este cambio solo afectará a los usuarios que extiendan Zend_Http_Client.

Algunos métodos de traducción especializados han quedado obsoletos porque duplican un comportamiento ya existente. Tenga en cuenta que los métodos antiguos seguirán funcionando, pero se activará un aviso de usuario que describe la nueva llamada. Los métodos se eliminarán en la versión 2.0. Consulte la siguiente lista para conocer la llamada de método antigua y la nueva.

Se realizó un pequeño cambio en la serie 1.9 para modificar el uso por defecto del dijit Editor para que utilice etiquetas div en lugar de una etiqueta textarea; este último uso tiene implicaciones de seguridad, y el uso de etiquetas div es lo recomendado por el proyecto Dojo.

Con el fin de seguir permitiendo la degradación elegante, se añadió una nueva opción degrade al helper de vista; esto permitía a los desarrolladores usar opcionalmente una etiqueta textarea en su lugar. Sin embargo, esto exponía a las aplicaciones desarrolladas con dicho uso a vectores de XSS. En la versión 1.9.7, hemos eliminado esta opción. La degradación elegante sigue estando soportada, no obstante, mediante una etiqueta noscript que incluye una textarea. Esta solución resuelve todos los problemas de seguridad.

La conclusión es que si estaba utilizando la marca degrade, esta simplemente se ignorará a partir de ahora.

Para utilizar por defecto una codificación de caracteres más segura, Zend_Filter_HtmlEntities ahora usa por defecto UTF-8 en lugar de ISO-8859-1.

Adicionalmente, dado que el mecanismo real trata con codificaciones de caracteres y no con conjuntos de caracteres, se han añadido dos nuevos métodos, setEncoding() y getEncoding(). Los métodos anteriores setCharSet() y setCharSet() ahora están obsoletos y actúan como proxy hacia los nuevos métodos. Por último, en lugar de usar los miembros protegidos directamente dentro del método filter(), estos miembros se obtienen a través de sus accesores explícitos. Si estaba extendiendo el filtro anteriormente, revise su código y sus pruebas unitarias para asegurarse de que todo sigue funcionando correctamente.

Zend_Filter_StripTags contiene una marca, commentsAllowed, que, en versiones anteriores, permitía incluir opcionalmente en una lista blanca los comentarios HTML en el texto HTML filtrado por la clase. Sin embargo, esto exponía al código que activaba esta marca a ataques de XSS, en particular en Internet Explorer (que permite especificar funcionalidad condicional mediante comentarios HTML). A partir de la versión 1.9.7 (y aplicado retroactivamente a las versiones 1.8.5 y 1.7.9), la marca commentsAllowed ya no tiene ningún efecto, y todos los comentarios HTML, incluidos aquellos que contienen otras etiquetas HTML o comentarios anidados, se eliminarán de la salida final del filtro.