Cleaned up the release notes index page, and added some stub 1.1.2 and 1.2 release notes.

    * **Django over time:**

      :ref:`API stability <misc-api-stability>` |

      :ref:`Release notes <releases-index>` |

      :ref:`Release notes and upgrading instructions <releases-index>` |

      :ref:`Deprecation Timeline <internals-deprecation>`

       ``django.views.decorators.csrf.csrf_protect`` on particular views you

       want to protect (see below).

    2. In any template that uses a POST form, use the ``csrf_token`` tag inside

    2. In any template that uses a POST form, use the :ttag:`csrf_token` tag inside

       the ``<form>`` element if the form is for an internal URL, e.g.::

           <form action="" method="POST">{% csrf_token %}

Use of the ``CsrfResponseMiddleware`` is not recommended because of the

performance hit it imposes, and because of a potential security problem (see

below).  It can be used as an interim measure until applications have been

updated to use the ``{% csrf_token %}`` tag.  It is deprecated and will be

updated to use the :ttag:`csrf_token` tag.  It is deprecated and will be

removed in Django 1.4.

Django 1.1 and earlier provided a single ``CsrfMiddleware`` class.  This is also

``CsrfViewMiddleware`` to your settings.  However, if you have supplied

customised templates to any of the view functions of contrib apps (whether

explicitly via a keyword argument, or by overriding built-in templates), **you

MUST update them** to include the ``csrf_token`` template tag as described

MUST update them** to include the :ttag:`csrf_token` template tag as described

above, or they will stop working.  (If you cannot update these templates for

some reason, you will be forced to use ``CsrfResponseMiddleware`` for these

views to continue working).

Caching

=======

If the ``csrf_token`` template tag is used by a template (or the ``get_token``

If the :ttag:`csrf_token` template tag is used by a template (or the ``get_token``

function is called some other way), ``CsrfViewMiddleware`` will add a cookie and

a ``Vary: Cookie`` header to the response.  Similarly,

``CsrfResponseMiddleware`` will send the ``Vary: Cookie`` header if it inserted

Ignore everything between ``{% comment %}`` and ``{% endcomment %}``

.. templatetag:: cycle

.. templatetag:: csrf_token

csrf_token

~~~~~~~~~~

protection, as described in the documentation for :ref:`Cross Site Request

Forgeries <ref-contrib-csrf>`.

.. templatetag:: cycle

cycle

~~~~~

.. _releases-1.1.2:

==============================================

Django 1.1.2 release notes — UNDER DEVELOPMENT

==============================================

This page documents release notes for the as-yet-unreleased Django

1.1.2. As such it is tentative and subject to change. It provides

up-to-date information for those who are following the 1.1.X branch.

This is the second "bugfix" release in the Django 1.1 series,

improving the stability and performance of the Django 1.1 codebase.

Django 1.1.2 maintains backwards compatibility with Django

1.1.0, but contain a number of fixes and other

improvements. Django 1.1.2 is a recommended upgrade for any

development or deployment currently using or targeting Django 1.1.

For full details on the new features, backwards incompatibilities, and

deprecated features in the 1.1 branch, see the :ref:`releases-1.1`.

One new feature

---------------

Ordinarily, a point release would not include new features, but in the

case of Django 1.1.2, we have made an exception to this rule. Django

1.2 (the next major release of Django) will contain a feature that

will improve protection against Cross-Site Request Forgery (CSRF)

attacks. This feature requires the use of a new :ttag:`csrf_token`

template tag in all forms that Django renders.

To make it easier to support both 1.1.X and 1.2.X versions of Django with

the same templates, we have decided to introduce the :ttag:`csrf_token` template

tag to the 1.1.X branch. In the 1.1.X branch, :ttag:`csrf_token` does nothing -

it has no effect on templates or form processing. However, it means that the

same template will work with Django 1.2.

it is tentative and subject to change.  It provides up-to-date information for

those who are following trunk.

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`_

.. _backwards-incompatible-changes-1.2:

Backwards-incompatible changes in 1.2

==========================

None.

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.

Email Backends

--------------

You can now :ref:`configure the way that Django sends email

<topic-email-backends>`. Instead of using SMTP to send all email, you

can now choose a configurable email backend to send messages. If your

hosting provider uses a sandbox or some other non-SMTP technique for

sending mail, you can now construct an email backend that will allow

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

backend implementations that allow you to send email to a

: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

email to be :ref:`thrown away<topic-email-console-backend>`.