2011-03-30 17:34:01 +00:00
|
|
|
============================================
|
|
|
|
|
Django 1.4 release notes - UNDER DEVELOPMENT
|
|
|
|
|
============================================
|
|
|
|
|
|
|
|
|
|
This page documents release notes for the as-yet-unreleased Django
|
|
|
|
|
1.4. As such, it's tentative and subject to change. It provides
|
|
|
|
|
up-to-date information for those who are following trunk.
|
|
|
|
|
|
|
|
|
|
Django 1.4 includes various `new features`_ and some minor `backwards
|
|
|
|
|
incompatible changes`_. There are also some features that have been dropped,
|
|
|
|
|
which are detailed in :doc:`our deprecation plan </internals/deprecation>`.
|
|
|
|
|
|
|
|
|
|
.. _new features: `What's new in Django 1.4`_
|
|
|
|
|
.. _backwards incompatible changes: backwards-incompatible-changes-1.4_
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
What's new in Django 1.4
|
|
|
|
|
========================
|
|
|
|
|
|
|
|
|
|
.. _backwards-incompatible-changes-1.4:
|
|
|
|
|
|
|
|
|
|
Backwards incompatible changes in 1.4
|
|
|
|
|
=====================================
|
2011-03-30 17:35:32 +00:00
|
|
|
|
|
|
|
|
Compatibility with old signed data
|
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
Django 1.3 changed the cryptographic signing mechanisms used in a number of
|
|
|
|
|
places in Django. While Django 1.3 kept fallbacks that would accept hashes
|
|
|
|
|
produced by the previous methods, these fallbacks are removed in Django 1.4.
|
|
|
|
|
|
|
|
|
|
So, if you upgrade to Django 1.4 directly from 1.2 or earlier, you may
|
|
|
|
|
lose/invalidate certain pieces of data that have been cryptographically signed
|
|
|
|
|
using an old method. To avoid this, use Django 1.3 first, for a period of time,
|
|
|
|
|
to allow the signed data to expire naturally. The affected parts are detailed
|
|
|
|
|
below, with 1) the consequences of ignoring this advice and 2) the amount of
|
|
|
|
|
time you need to run Django 1.3 for the data to expire or become irrelevant.
|
|
|
|
|
|
|
|
|
|
* contrib.sessions data integrity check
|
|
|
|
|
|
|
|
|
|
* consequences: the user will be logged out, and session data will be lost.
|
|
|
|
|
|
|
|
|
|
* time period: defined by SESSION_COOKIE_AGE.
|
|
|
|
|
|
|
|
|
|
* contrib.auth password reset hash
|
|
|
|
|
|
|
|
|
|
* consequences: password reset links from before the upgrade will not work.
|
|
|
|
|
|
|
|
|
|
* time period: defined by PASSWORD_RESET_TIMEOUT_DAYS.
|
|
|
|
|
|
|
|
|
|
Form related hashes — these are much shorter lifetime, and are relevant only for
|
|
|
|
|
the short window where a user might fill in a form generated by the pre-upgrade
|
|
|
|
|
Django instance, and try to submit it to the upgraded Django instance:
|
|
|
|
|
|
|
|
|
|
* contrib.comments form security hash
|
|
|
|
|
|
|
|
|
|
* consequences: the user will see a validation error "Security hash failed".
|
|
|
|
|
|
|
|
|
|
* time period: the amount of time you expect users to take filling out comment
|
|
|
|
|
forms.
|
|
|
|
|
|
|
|
|
|
* FormWizard security hash
|
|
|
|
|
|
|
|
|
|
* consequences: the user will see an error about the form having expired,
|
|
|
|
|
and will be sent back to the first page of the wizard, losing the data
|
|
|
|
|
they have inputted so far.
|
|
|
|
|
|
|
|
|
|
* time period: the amount of time you expect users to take filling out the
|
|
|
|
|
affected forms.
|
|
|
|
|
|
|
|
|
|
* CSRF check
|
|
|
|
|
|
|
|
|
|
* Note: This is actually a Django 1.1 fallback, not Django 1.2,
|
|
|
|
|
and applies only if you are upgrading from 1.1.
|
|
|
|
|
|
|
|
|
|
* consequences: the user will see a 403 error with any CSRF protected POST
|
|
|
|
|
form.
|
|
|
|
|
|
|
|
|
|
* time period: the amount of time you expect user to take filling out
|
|
|
|
|
such forms.
|
