2015-05-26 22:18:21 +00:00
|
|
|
==========================
|
|
|
|
Django 1.7.9 release notes
|
|
|
|
==========================
|
|
|
|
|
2015-06-15 22:29:46 +00:00
|
|
|
*July 8, 2015*
|
2015-05-26 22:18:21 +00:00
|
|
|
|
2015-06-15 22:29:46 +00:00
|
|
|
Django 1.7.9 fixes several security issues and bugs in 1.7.8.
|
|
|
|
|
2015-06-10 21:45:20 +00:00
|
|
|
Denial-of-service possibility by filling session store
|
|
|
|
======================================================
|
|
|
|
|
|
|
|
In previous versions of Django, the session backends created a new empty record
|
|
|
|
in the session storage anytime ``request.session`` was accessed and there was a
|
|
|
|
session key provided in the request cookies that didn't already have a session
|
|
|
|
record. This could allow an attacker to easily create many new session records
|
|
|
|
simply by sending repeated requests with unknown session keys, potentially
|
|
|
|
filling up the session store or causing other users' session records to be
|
|
|
|
evicted.
|
|
|
|
|
|
|
|
The built-in session backends now create a session record only if the session
|
|
|
|
is actually modified; empty session records are not created. Thus this
|
|
|
|
potential DoS is now only possible if the site chooses to expose a
|
|
|
|
session-modifying view to anonymous users.
|
|
|
|
|
|
|
|
As each built-in session backend was fixed separately (rather than a fix in the
|
|
|
|
core sessions framework), maintainers of third-party session backends should
|
|
|
|
check whether the same vulnerability is present in their backend and correct
|
|
|
|
it if so.
|
|
|
|
|
2015-06-15 22:29:46 +00:00
|
|
|
Bugfixes
|
|
|
|
========
|
2015-05-26 22:18:21 +00:00
|
|
|
|
|
|
|
* Prevented the loss of ``null``/``not null`` column properties during field
|
|
|
|
renaming of MySQL databases (:ticket:`24817`).
|
2015-05-09 23:13:05 +00:00
|
|
|
|
|
|
|
* Fixed ``SimpleTestCase.assertRaisesMessage()`` on Python 2.7.10
|
|
|
|
(:ticket:`24903`).
|