Welcome to Django 1.2.5!
\nThis is the fifth “bugfix” release in the Django 1.2 series,\nimproving the stability and performance of the Django 1.2 codebase.
\nWith four exceptions, Django 1.2.5 maintains backwards compatibility\nwith Django 1.2.4. It also contains a number of fixes and other\nimprovements. Django 1.2.5 is a recommended upgrade for any\ndevelopment or deployment currently using or targeting Django 1.2.
\nFor full details on the new features, backwards incompatibilities, and\ndeprecated features in the 1.2 branch, see the Django 1.2 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.
\nIn earlier Django versions, when a model instance containing a\nFileField was deleted,\nFileField took it upon itself to also delete the\nfile from the backend storage. This opened the door to several potentially\nserious data-loss scenarios, including rolled-back transactions and fields on\ndifferent models referencing the same file. In Django 1.2.5,\nFileField will never delete files from the backend\nstorage. If you need cleanup of orphaned files, you’ll need to handle it\nyourself (for instance, with a custom management command that can be run\nmanually or scheduled to run periodically via e.g. cron).
Django provides a custom SQL hooks as a way to inject hand-crafted SQL\ninto the database synchronization process. One of the possible uses\nfor this custom SQL is to insert data into your database. If your\ncustom SQL contains INSERT statements, those insertions will be\nperformed every time your database is synchronized. This includes the\nsynchronization of any test databases that are created when you run a\ntest suite.
However, in the process of testing the Django 1.3, it was discovered\nthat this feature has never completely worked as advertised. When\nusing database backends that don’t support transactions, or when using\na TransactionTestCase, data that has been inserted using custom SQL\nwill not be visible during the testing process.
\nUnfortunately, there was no way to rectify this problem without\nintroducing a backwards incompatibility. Rather than leave\nSQL-inserted initial data in an uncertain state, Django now enforces\nthe policy that data inserted by custom SQL will not be visible\nduring testing.
\nThis change only affects the testing process. You can still use custom\nSQL to load data into your production database as part of the syncdb\nprocess. If you require data to exist during test conditions, you\nshould either insert it using test fixtures, or using the setUp() method of your\ntest case.
Django 1.2.4 introduced a method lookup_allowed on ModelAdmin, to cope\nwith a security issue (changeset [15033]). Although this method was never\ndocumented, it seems some people have overridden lookup_allowed, especially\nto cope with regressions introduced by that changeset. While the method is\nstill undocumented and not marked as stable, it may be helpful to know that the\nsignature of this function has changed.