/docs/releases/1.1.4.txt

 1==========================
 2Django 1.1.4 release notes
 3==========================
 4
 5Welcome to Django 1.1.4!
 6
 7This is the fourth "bugfix" release in the Django 1.1 series,
 8improving the stability and performance of the Django 1.1 codebase.
 9
10With one exception, Django 1.1.4 maintains backwards compatibility
11with Django 1.1.3. It also contains a number of fixes and other
12improvements. Django 1.1.4 is a recommended upgrade for any
13development or deployment currently using or targeting Django 1.1.
14
15For full details on the new features, backwards incompatibilities, and
16deprecated features in the 1.1 branch, see the :doc:`/releases/1.1`.
17
18Backwards incompatible changes
19==============================
20
21CSRF exception for AJAX requests
22~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
23
24Django includes a CSRF-protection mechanism, which makes use of a
25token inserted into outgoing forms. Middleware then checks for the
26token's presence on form submission, and validates it.
27
28Prior to Django 1.2.5, our CSRF protection made an exception for AJAX
29requests, on the following basis:
30
31    * Many AJAX toolkits add an X-Requested-With header when using
32      XMLHttpRequest.
33
34    * Browsers have strict same-origin policies regarding
35      XMLHttpRequest.
36
37    * In the context of a browser, the only way that a custom header
38      of this nature can be added is with XMLHttpRequest.
39
40Therefore, for ease of use, we did not apply CSRF checks to requests
41that appeared to be AJAX on the basis of the X-Requested-With header.
42The Ruby on Rails web framework had a similar exemption.
43
44Recently, engineers at Google made members of the Ruby on Rails
45development team aware of a combination of browser plugins and
46redirects which can allow an attacker to provide custom HTTP headers
47on a request to any website. This can allow a forged request to appear
48to be an AJAX request, thereby defeating CSRF protection which trusts
49the same-origin nature of AJAX requests.
50
51Michael Koziarski of the Rails team brought this to our attention, and
52we were able to produce a proof-of-concept demonstrating the same
53vulnerability in Django's CSRF handling.
54
55To remedy this, Django will now apply full CSRF validation to all
56requests, regardless of apparent AJAX origin. This is technically
57backwards-incompatible, but the security risks have been judged to
58outweigh the compatibility concerns in this case.
59
60Additionally, Django will now accept the CSRF token in the custom HTTP
61header X-CSRFTOKEN, as well as in the form submission itself, for ease
62of use with popular JavaScript toolkits which allow insertion of
63custom headers into all AJAX requests.
64
65Please see the :ref:`CSRF docs for example jQuery code <csrf-ajax>`
66that demonstrates this technique, ensuring that you are looking at the
67documentation for your version of Django, as the exact code necessary
68is different for some older versions of Django.