2009-11-15 03:13:33 +08:00
|
|
|
.. _releases-1.2:
|
2009-10-20 05:48:06 +08:00
|
|
|
|
2009-11-15 03:13:33 +08:00
|
|
|
============================================
|
|
|
|
Django 1.2 release notes — UNDER DEVELOPMENT
|
|
|
|
============================================
|
|
|
|
|
|
|
|
This page documents release notes for the as-yet-unreleased Django 1.2. As such
|
|
|
|
it is tentative and subject to change. It provides up-to-date information for
|
|
|
|
those who are following trunk.
|
|
|
|
|
2009-11-23 21:44:24 +08:00
|
|
|
Django 1.2 includes a number of nifty `new features`_, lots of bug
|
|
|
|
fixes, and an easy upgrade path from Django 1.1.
|
|
|
|
|
|
|
|
.. _new features: `What's new in Django 1.2`_
|
|
|
|
|
2009-11-15 03:13:33 +08:00
|
|
|
.. _backwards-incompatible-changes-1.2:
|
|
|
|
|
|
|
|
Backwards-incompatible changes in 1.2
|
|
|
|
=====================================
|
2009-10-20 05:48:06 +08:00
|
|
|
|
Fixed #9977 - CsrfMiddleware gets template tag added, session dependency removed, and turned on by default.
This is a large change to CSRF protection for Django. It includes:
* removing the dependency on the session framework.
* deprecating CsrfResponseMiddleware, and replacing with a core template tag.
* turning on CSRF protection by default by adding CsrfViewMiddleware to
the default value of MIDDLEWARE_CLASSES.
* protecting all contrib apps (whatever is in settings.py)
using a decorator.
For existing users of the CSRF functionality, it should be a seamless update,
but please note that it includes DEPRECATION of features in Django 1.1,
and there are upgrade steps which are detailed in the docs.
Many thanks to 'Glenn' and 'bthomas', who did a lot of the thinking and work
on the patch, and to lots of other people including Simon Willison and
Russell Keith-Magee who refined the ideas.
Details of the rationale for these changes is found here:
http://code.djangoproject.com/wiki/CsrfProtection
As of this commit, the CSRF code is mainly in 'contrib'. The code will be
moved to core in a separate commit, to make the changeset as readable as
possible.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11660 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2009-10-27 07:23:07 +08:00
|
|
|
CSRF Protection
|
|
|
|
---------------
|
|
|
|
|
|
|
|
There have been large changes to the way that CSRF protection works, detailed in
|
|
|
|
:ref:`the CSRF documentaton <ref-contrib-csrf>`. The following are the major
|
|
|
|
changes that developers must be aware of:
|
|
|
|
|
|
|
|
* ``CsrfResponseMiddleware`` and ``CsrfMiddleware`` have been deprecated, and
|
2009-12-03 22:48:47 +08:00
|
|
|
will be removed completely in Django 1.4, in favor of a template tag that
|
Fixed #9977 - CsrfMiddleware gets template tag added, session dependency removed, and turned on by default.
This is a large change to CSRF protection for Django. It includes:
* removing the dependency on the session framework.
* deprecating CsrfResponseMiddleware, and replacing with a core template tag.
* turning on CSRF protection by default by adding CsrfViewMiddleware to
the default value of MIDDLEWARE_CLASSES.
* protecting all contrib apps (whatever is in settings.py)
using a decorator.
For existing users of the CSRF functionality, it should be a seamless update,
but please note that it includes DEPRECATION of features in Django 1.1,
and there are upgrade steps which are detailed in the docs.
Many thanks to 'Glenn' and 'bthomas', who did a lot of the thinking and work
on the patch, and to lots of other people including Simon Willison and
Russell Keith-Magee who refined the ideas.
Details of the rationale for these changes is found here:
http://code.djangoproject.com/wiki/CsrfProtection
As of this commit, the CSRF code is mainly in 'contrib'. The code will be
moved to core in a separate commit, to make the changeset as readable as
possible.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11660 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2009-10-27 07:23:07 +08:00
|
|
|
should be inserted into forms.
|
|
|
|
|
2009-10-27 20:11:56 +08:00
|
|
|
* All contrib apps use a ``csrf_protect`` decorator to protect the view. This
|
|
|
|
requires the use of the csrf_token template tag in the template, so if you
|
2009-12-03 22:48:47 +08:00
|
|
|
have used custom templates for contrib views, you MUST READ THE :ref:`UPGRADE
|
|
|
|
INSTRUCTIONS <ref-csrf-upgrading-notes>` to fix those templates.
|
2009-10-27 20:11:56 +08:00
|
|
|
|
Fixed #9977 - CsrfMiddleware gets template tag added, session dependency removed, and turned on by default.
This is a large change to CSRF protection for Django. It includes:
* removing the dependency on the session framework.
* deprecating CsrfResponseMiddleware, and replacing with a core template tag.
* turning on CSRF protection by default by adding CsrfViewMiddleware to
the default value of MIDDLEWARE_CLASSES.
* protecting all contrib apps (whatever is in settings.py)
using a decorator.
For existing users of the CSRF functionality, it should be a seamless update,
but please note that it includes DEPRECATION of features in Django 1.1,
and there are upgrade steps which are detailed in the docs.
Many thanks to 'Glenn' and 'bthomas', who did a lot of the thinking and work
on the patch, and to lots of other people including Simon Willison and
Russell Keith-Magee who refined the ideas.
Details of the rationale for these changes is found here:
http://code.djangoproject.com/wiki/CsrfProtection
As of this commit, the CSRF code is mainly in 'contrib'. The code will be
moved to core in a separate commit, to make the changeset as readable as
possible.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11660 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2009-10-27 07:23:07 +08:00
|
|
|
* ``CsrfViewMiddleware`` is included in :setting:`MIDDLEWARE_CLASSES` by
|
|
|
|
default. This turns on CSRF protection by default, so that views that accept
|
|
|
|
POST requests need to be written to work with the middleware. Instructions
|
|
|
|
on how to do this are found in the CSRF docs.
|
|
|
|
|
2009-10-27 08:36:34 +08:00
|
|
|
* All of the CSRF has moved from contrib to core (with backwards compatible
|
|
|
|
imports in the old locations, which are deprecated).
|
|
|
|
|
2009-10-20 05:48:06 +08:00
|
|
|
LazyObject
|
|
|
|
----------
|
|
|
|
|
|
|
|
``LazyObject`` is an undocumented utility class used for lazily wrapping other
|
|
|
|
objects of unknown type. In Django 1.1 and earlier, it handled introspection in
|
|
|
|
a non-standard way, depending on wrapped objects implementing a public method
|
|
|
|
``get_all_members()``. Since this could easily lead to name clashes, it has been
|
|
|
|
changed to use the standard method, involving ``__members__`` and ``__dir__()``.
|
|
|
|
If you used ``LazyObject`` in your own code, and implemented the
|
|
|
|
``get_all_members()`` method for wrapped objects, you need to make the following
|
|
|
|
changes:
|
|
|
|
|
|
|
|
* If your class does not have special requirements for introspection (i.e. you
|
|
|
|
have not implemented ``__getattr__()`` or other methods that allow for
|
|
|
|
attributes not discoverable by normal mechanisms), you can simply remove the
|
|
|
|
``get_all_members()`` method. The default implementation on ``LazyObject``
|
|
|
|
will do the right thing.
|
|
|
|
|
|
|
|
* If you have more complex requirements for introspection, first rename the
|
|
|
|
``get_all_members()`` method to ``__dir__()``. This is the standard method,
|
|
|
|
from Python 2.6 onwards, for supporting introspection. If you are require
|
|
|
|
support for Python < 2.6, add the following code to the class::
|
|
|
|
|
|
|
|
__members__ = property(lambda self: self.__dir__())
|
2009-11-15 03:13:33 +08:00
|
|
|
|
|
|
|
.. _deprecated-features-1.2:
|
|
|
|
|
|
|
|
Features deprecated in 1.2
|
|
|
|
==========================
|
|
|
|
|
2009-12-03 22:48:47 +08:00
|
|
|
CSRF response rewriting middleware
|
|
|
|
----------------------------------
|
|
|
|
|
|
|
|
``CsrfResponseMiddleware``, the middleware that automatically inserted CSRF
|
|
|
|
tokens into POST forms in outgoing pages, has been deprecated in favor of a
|
|
|
|
template tag method (see above), and will be removed completely in Django
|
|
|
|
1.4. ``CsrfMiddleware``, which includes the functionality of
|
|
|
|
``CsrfResponseMiddleware`` and ``CsrfViewMiddleware`` has likewise been
|
|
|
|
deprecated.
|
|
|
|
|
|
|
|
Also, the CSRF module has moved from contrib to core, and the old imports are
|
|
|
|
deprecated, as described in the :ref:`upgrading notes <ref-csrf-upgrading-notes>`.
|
|
|
|
|
|
|
|
``SMTPConnection``
|
|
|
|
------------------
|
|
|
|
|
|
|
|
This class has been deprecated in favor of the new generic e-mail backends.
|
2009-11-23 21:44:24 +08:00
|
|
|
|
|
|
|
What's new in Django 1.2
|
|
|
|
========================
|
|
|
|
|
|
|
|
CSRF support
|
|
|
|
------------
|
|
|
|
|
|
|
|
Django now has much improved protection against :ref:`Cross-Site
|
|
|
|
Request Forgery (CSRF) attacks<ref-contrib-csrf>`. This type of attack
|
|
|
|
occurs when a malicious Web site contains a link, a form button or
|
|
|
|
some javascript that is intended to perform some action on your Web
|
|
|
|
site, using the credentials of a logged-in user who visits the
|
|
|
|
malicious site in their browser. A related type of attack, 'login
|
|
|
|
CSRF', where an attacking site tricks a user's browser into logging
|
|
|
|
into a site with someone else's credentials, is also covered.
|
|
|
|
|
2009-12-03 22:55:28 +08:00
|
|
|
E-mail Backends
|
|
|
|
---------------
|
2009-11-23 21:44:24 +08:00
|
|
|
|
2009-12-03 22:55:28 +08:00
|
|
|
You can now :ref:`configure the way that Django sends e-mail
|
|
|
|
<topic-email-backends>`. Instead of using SMTP to send all e-mail, you
|
|
|
|
can now choose a configurable e-mail backend to send messages. If your
|
2009-11-23 21:44:24 +08:00
|
|
|
hosting provider uses a sandbox or some other non-SMTP technique for
|
2009-12-03 22:55:28 +08:00
|
|
|
sending mail, you can now construct an e-mail backend that will allow
|
2009-11-23 21:44:24 +08:00
|
|
|
Django's standard :ref:`mail sending methods<topics-email>` to use
|
|
|
|
those facilities.
|
|
|
|
|
|
|
|
This also makes it easier to debug mail sending - Django ships with
|
2009-12-03 22:55:28 +08:00
|
|
|
backend implementations that allow you to send e-mail to a
|
2009-11-23 21:44:24 +08:00
|
|
|
:ref:`file<topic-email-file-backend>`, to the
|
|
|
|
:ref:`console<topic-email-console-backend>`, or to
|
|
|
|
:ref:`memory<topic-email-memory-backend>` - you can even configure all
|
2009-12-03 22:55:28 +08:00
|
|
|
e-mail to be :ref:`thrown away<topic-email-dummy-backend>`.
|
2009-11-23 21:44:24 +08:00
|
|
|
|