Bienvenido a Django 1.2.5!
Este es el quinto «bugfix» lanzamiento en la serie Django 1.2, que mejora la estabilidad y rendimiento del código base de Django 1.2.
Conseguir cuatro excepciones, Django 1.2.5 mantiene la compatibilidad hacia atrás con Django 1.2.4. También contiene un número de correcciones y otras mejoras. Django 1.2.5 es una actualización recomendada para cualquier desarrollo o implementación que esté utilizando o apuntando a Django 1.2.
Para obtener detalles completos sobre las nuevas características, incompatibilidades hacia atrás y características obsoletas en la rama 1.2, consulte el Notas de lanzamiento de Django 1.2.
Django incluye un mecanismo de protección contra ataques CSRF, que utiliza un token insertado en las formas salientes. El middleware luego verifica la presencia del token y lo valida al enviar la forma.
Antes de Django 1.2.5, nuestra protección CSRF hacía una excepción para solicitudes AJAX, con la siguiente base:
Muchas herramientas de AJAX agregan un encabezado X-Requested-With cuando se utiliza XMLHttpRequest.
Los navegadores tienen políticas de origen estrictas en cuanto a XMLHttpRequest.
En el contexto de un navegador, la única forma en que se puede agregar una cabecera personalizada de esta naturaleza es con XMLHttpRequest.
Por lo tanto, para facilitar su uso, no aplicamos comprobaciones CSRF a las solicitudes que parecían ser AJAX en función de la cabecera X-Requested-With. El framework web Ruby on Rails tenía una exención similar.
Recientemente, ingenieros de Google informaron a los miembros del equipo de desarrollo de Ruby on Rails sobre una combinación de complementos de navegador y redirecciones que pueden permitir a un atacante proporcionar cabeceras HTTP personalizadas en una solicitud a cualquier sitio web. Esto puede permitir que una solicitud falsificada aparezca como una solicitud AJAX, lo que vuelve inútil la protección CSRF que confía en la naturaleza de origen del mismo origen de las solicitudes AJAX.
Michael Koziarski del equipo de Rails les llamó la atención a esto y pudimos producir un ejemplo de concepto demostrando la misma vulnerabilidad en el manejo de CSRF de Django.
Para remediar esto, Django ahora aplicará comprobaciones CSRF completas a todas las solicitudes, sin importar el origen AJAX aparente. Esto es técnicamente incompatibilidad hacia atrás, pero los riesgos de seguridad se han juzgado superiores a las preocupaciones de compatibilidad en este caso.
Además, Django ahora aceptará el token CSRF en la cabecera HTTP personalizada X-CSRFTOKEN, así como en la presentación del formulario en sí mismo, para facilitar su uso con los conjuntos de herramientas JavaScript populares que permiten la inserción de cabeceras personalizadas en todas las solicitudes AJAX.
Por favor, consulte el docs de CSRF para ejemplo de código jQuery que demuestra esta técnica, asegurándose de que esté mirando la documentación para su versión de Django, ya que el código exacto necesario es diferente para algunas versiones antiguas de Django.
En versiones anteriores de Django, cuando se eliminaba una instancia de modelo que contenía un FileField, FileField se encargaba de eliminar también el archivo desde el almacenamiento backend. Esto abría la puerta a varios escenarios potencialmente graves de pérdida de datos, incluyendo transacciones anuladas y campos en modelos diferentes que hacen referencia al mismo archivo. En Django 1.2.5, FileField nunca eliminará archivos desde el almacenamiento backend. Si necesitas limpiar archivos huérfanos, deberás manejarlo tú mismo (por ejemplo, con un comando de gestión personalizado que se puede ejecutar manualmente o programado para ejecutarse periódicamente mediante e.g. cron).
Django proporciona hooks de SQL personalizados como una forma de inyectar SQL manualmente en el proceso de sincronización del servidor de bases de datos. Uno de los posibles usos de este SQL personalizado es insertar datos en tu base de datos. Si tu SQL personalizado contiene INSERT declaraciones, esas inserciones se realizarán cada vez que se sincronice tu base de datos. Esto incluye la sincronización de cualquier base de datos de prueba creada cuando ejecutas un conjunto de pruebas.
Sin embargo, en el proceso de probar Django 1.3, se descubrió que esta característica nunca funcionó completamente como se anunciaba. Cuando se utilizan motores de bases de datos que no admiten transacciones o cuando se utiliza una TransactionTestCase, los datos insertados mediante SQL personalizado no serán visibles durante el proceso de prueba.
Desafortunadamente, no había forma de rectificar este problema sin introducir incompatibilidad hacia atrás. En lugar de dejar que los datos insertados por SQL personalizado estén en un estado incierto, Django ahora aplica la política de que los datos insertados mediante SQL personalizado no serán visibles durante el proceso de prueba.
Este cambio solo afecta al proceso de prueba. Puedes seguir utilizando SQL personalizado para cargar datos en tu base de datos de producción como parte del proceso syncdb. Si requieres que los datos existan durante las condiciones de prueba, deberás insertarlos usando fijaciones de prueba, o mediante el método setUp() de tu caso de prueba.
Django 1.2.4 introdujo un método lookup_allowed en ModelAdmin, para abordar una cuestión de seguridad (cambioset [15033]). Aunque este método nunca estuvo documentado, parece que algunas personas lo han sobrescrito, especialmente para abordar las regresiones introducidas por ese cambioset. Si bien el método sigue siendo no documentado y no está marcado como estable, puede ser útil saber que la firma de esta función ha cambiado.
may 31, 2026