Con un poco de retraso publicamos el resumen de la última reunión del año 2011 del grupo de desarrolladores de Symfony:

1. Permitir la carga asíncrona de contenidos en el cliente mediante la etiqueta {% render %} de Twig (ver PR #2865) se ha propuesto mediante una pull request la posibilidad de añadir soporte para cargar trozos de página de forma asíncrona mediante JavaScript. Se decide que la idea es buena, pero la implementación no. El problema es que se está reinventando la rueda, ya que existe una tecnología buena y probada que hace esto muy bien: hinclude.js. Se trata del equivalente de ESI para la parte del cliente. Se decide probar la integración de hinclude.js dentro del core de Symfony2. Si el resultado es bueno y no ensucia demasiado su código o las plantillas, se incorporará. Ver PR #2903 para conocer los detalles de la integración.

2. Añadir los métodos Kernel::terminate() y HttpKernel::terminate() para ejecutar código después de enviar la respuesta al usuario (ver PR #2791) la propuesta se acepta sin mucha discusión, ya que se considera algo realmente útil. No es algo que pueda sustituir a Gearman o RabbitMQ, pero puede venir muy bien en acciones puntuales con un procesamiento pesado o complejo y para la que no merece la pena o no se pueden instalar las herramientas anteriores.

3. Renombrado el método equals() a isSameUser() en la interfaz UserInterface (ver PR #2669) durante la reunión se volvió a discutir una vez más sobre el famoso método equals() de la interfaz UserInterface. El problema es que este nombre entra en conflicto con otras librerías (sobre todo con Propel) y según algunos no refleja realmente su propósito: este método no sólo comprueba que el usuario que te pasan sea el mismo, sino que también hay que comprobar si sigue siendo válido desde el punto de vista de la autenticación. Se proponen como alternativas:

• isSameUser()
• equalsUser()
• isSameAs()
• isSameAsValidAutenticatedUser()
• isStillConsideredAsValidForAuthentication()

Antes de que a alguien se le ocurrieran métodos con nombres todavía más largos, se propone eliminar el método equals() de la interfaz. ¿Por qué tienen los programadores que comprobar si el usuario es el mismo y sigue siendo válido? Que lo haga Symfony2 automáticamente y si quiero hacer cosas avanzadas, ya crearé una clase o implementaré una interfaz especial. Ver PR #2927 para los detalles de la nueva implementación.

Como siempre, también puedes leer los logs completos de la reunión para conocer los detalles discutidos para cada punto del orden del día.

El blog oficial de Symfony acaba de anunciar la publicación de Symfony 2.0.6, que corrige un error de seguridad grave relacionado con Doctrine2.

El error es muy fácil de reproducir:

• El usuario accede al formulario que le permite modificar los datos de su perfil.
• El usuario cambia su username por cualquier otro que ya exista en la aplicación.
• Se le mostrará un error indicando que el nuevo username ya existe.
• El problema es que además, se acaba de cambiar al usuario por el nuevo username.
• El usuario puede acceder a la aplicación como si fuera el username indicado anteriormente.

$ php bin/vendors install

$ php app/console cache:clear

Fuente: Security Release: Symfony 2.0.6

El pasado 13 de enero de 2011 el proyecto Symfony iniciaba una campaña de recogida de donativos para financiar una auditoría de seguridad del código fuente de Symfony2 y de Twig. El total necesario eran 6.000 euros y, gracias a la generosidad de de la comunidad Symfony, se recaudaron más de 8.200 euros a los pocos días.

Han pasado más de 10 meses desde ese anuncio y el código de Symfony ya ha sido exhaustivamente auditado. Las buenas noticias son que el código original era tan bueno que la empresa SektionEins encargada de la auditoría sólo ha podido encontrar incidencias menores.

El blog oficial de Symfony publica el listado completo de errores encontrados y enlaces a los commits que los solucionan. Igualmente, el blog de Twig ha publicado el brevísimo listado con los dos errores encontrados en su auditoría.  Teniendo en cuenta que el total entre los dos proyectos son unas 15 incidencias y que el coste fueron 6.000 euros,  el bug sale a 400 euros (bastante barato si se compara con Mozilla y Google Chrome, que pagan hasta 3.000 dólares a quien descubra un error en su código).

Así que a la larga lista de razones para utilizar Symfony2, ya podemos añadir el título de ser probablemente el framework PHP más seguro que exista. Y si además de Symfony2 utilizas algún otro framework, no olvides preguntarles cuántas auditorías de seguridad independientes han realizado de su código fuente.

Fuente: Symfony2 Security Audit

Formularios y Seguridad fue la cuarta ponencia impartida durante el primer día de las Jornadas Symfony 2011. Se trata de la cuarta parte de las seis que forman el tutorial de desarrollo de la aplicación deSymfony.

Javier López, de la empresa Flai, desarrolló durante su ponencia el formulario de registro completo con Symfony2, mostró las posibilidades de personalización de la vista de los formularios, el componente de seguridad, la definición de firewalls y la creación de un sistema de login con los usuarios de la aplicación.

Presentación

Vídeo

El proyecto Symfony acaba de publicar una actualización de seguridad para las ramas 1.3 y 1.4. Esta actualización es debida a una grave vulnerabilidad descubierta en Doctrine 1.2.3 y 2.0.2 que permite los ataques de inyección de código SQL. Por tanto, se recomienda actualizar inmediatamente todas las aplicaciones que utilicen symfony 1.3 y 1.4.

Además, esta actualización será la última de la rama 1.3.x, por lo que es una buena idea actualizar tus proyectos a 1.4.x, que será mantenida hasta noviembre del año 2012.

Como siempre, para actualizar tu versión de Symfony:

• Si usas el sandbox, te lo tienes que bajar otra vez.
• Si lo has instalado mediante el archivo comprimido de Symfony, te lo tienes que bajar otra vez desde www.symfony-project.org/installation/1_3 o www.symfony-project.org/installation/1_4 y debes descomprimirlo en el mismo directorio dentro de tu proyecto.
• Si lo has instalado mediante PEAR, ejecuta el comando pear upgrade symfony/symfony-1.3.10 o pear upgrade symfony/symfony-1.4.10
• Si lo instalas mediante Subversion, ejecuta el comando svn checkout http://svn.symfony-project.com/tags/RELEASE_1_3_10/ o svn checkout http://svn.symfony-project.com/tags/RELEASE_1_4_10/

Independientemente de cómo lo actualices, no olvides borrar la caché de cada proyecto después de la actualización mediante los siguientes comandos:

Si utilizas Doctrine:

$ php symfony doctrine:build --all-classes
$ php symfony cache:clear

Si utilizas Propel:

$ php symfony propel:build --all-classes
$ php symfony cache:clear

Fuente: symfony 1.3.10 and 1.4.10: security releases