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

Django 1.1.4 release notes

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

Welcome to Django 1.1.4!

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

improving the stability and performance of the Django 1.1 codebase.

With one exception, Django 1.1.4 maintains backwards compatibility

with Django 1.1.3. It also contains a number of fixes and other

improvements. Django 1.1.4 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 :doc:`/releases/1.1`.

Backwards incompatible changes

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

CSRF exception for AJAX requests

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

Django includes a CSRF-protection mechanism, which makes use of a

token inserted into outgoing forms. Middleware then checks for the

token's presence on form submission, and validates it.

Prior to Django 1.2.5, our CSRF protection made an exception for AJAX

requests, on the following basis:

* Many AJAX toolkits add an X-Requested-With header when using

  XMLHttpRequest.

* Browsers have strict same-origin policies regarding

  XMLHttpRequest.

* In the context of a browser, the only way that a custom header

  of this nature can be added is with XMLHttpRequest.

Therefore, for ease of use, we did not apply CSRF checks to requests

that appeared to be AJAX on the basis of the X-Requested-With header.

The Ruby on Rails web framework had a similar exemption.

Recently, engineers at Google made members of the Ruby on Rails

development team aware of a combination of browser plugins and

redirects which can allow an attacker to provide custom HTTP headers

on a request to any website. This can allow a forged request to appear

to be an AJAX request, thereby defeating CSRF protection which trusts

the same-origin nature of AJAX requests.

Michael Koziarski of the Rails team brought this to our attention, and

we were able to produce a proof-of-concept demonstrating the same

vulnerability in Django's CSRF handling.

To remedy this, Django will now apply full CSRF validation to all

requests, regardless of apparent AJAX origin. This is technically

backwards-incompatible, but the security risks have been judged to

outweigh the compatibility concerns in this case.

Additionally, Django will now accept the CSRF token in the custom HTTP

header X-CSRFTOKEN, as well as in the form submission itself, for ease

of use with popular JavaScript toolkits which allow insertion of

custom headers into all AJAX requests.

Please see the :ref:`CSRF docs for example jQuery code <csrf-ajax>`

that demonstrates this technique, ensuring that you are looking at the

documentation for your version of Django, as the exact code necessary

is different for some older versions of Django.