Welcome to Django 1.1.4!
\nThis is the fourth “bugfix” release in the Django 1.1 series,\nimproving the stability and performance of the Django 1.1 codebase.
\nWith one exception, Django 1.1.4 maintains backwards compatibility\nwith Django 1.1.3. It also contains a number of fixes and other\nimprovements. Django 1.1.4 is a recommended upgrade for any\ndevelopment or deployment currently using or targeting Django 1.1.
\nFor full details on the new features, backwards incompatibilities, and\ndeprecated features in the 1.1 branch, see the Django 1.1 release notes.
\nDjango includes a CSRF-protection mechanism, which makes use of a\ntoken inserted into outgoing forms. Middleware then checks for the\ntoken’s presence on form submission, and validates it.
\nPrior to Django 1.2.5, our CSRF protection made an exception for AJAX\nrequests, on the following basis:
\nMany AJAX toolkits add an X-Requested-With header when using\nXMLHttpRequest.
Browsers have strict same-origin policies regarding\nXMLHttpRequest.
In the context of a browser, the only way that a custom header\nof this nature can be added is with XMLHttpRequest.
Therefore, for ease of use, we did not apply CSRF checks to requests\nthat appeared to be AJAX on the basis of the X-Requested-With header.\nThe Ruby on Rails web framework had a similar exemption.
\nRecently, engineers at Google made members of the Ruby on Rails\ndevelopment team aware of a combination of browser plugins and\nredirects which can allow an attacker to provide custom HTTP headers\non a request to any website. This can allow a forged request to appear\nto be an AJAX request, thereby defeating CSRF protection which trusts\nthe same-origin nature of AJAX requests.
\nMichael Koziarski of the Rails team brought this to our attention, and\nwe were able to produce a proof-of-concept demonstrating the same\nvulnerability in Django’s CSRF handling.
\nTo remedy this, Django will now apply full CSRF validation to all\nrequests, regardless of apparent AJAX origin. This is technically\nbackwards-incompatible, but the security risks have been judged to\noutweigh the compatibility concerns in this case.
\nAdditionally, Django will now accept the CSRF token in the custom HTTP\nheader X-CSRFTOKEN, as well as in the form submission itself, for ease\nof use with popular JavaScript toolkits which allow insertion of\ncustom headers into all AJAX requests.
\nPlease see the CSRF docs for example jQuery code\nthat demonstrates this technique, ensuring that you are looking at the\ndocumentation for your version of Django, as the exact code necessary\nis different for some older versions of Django.
\n