PageRenderTime 15ms CodeModel.GetById 12ms app.highlight 1ms RepoModel.GetById 1ms app.codeStats 0ms

Plain Text | 123 lines | 97 code | 26 blank | 0 comment | 0 complexity | 938091ce80b19f4d389379cd0e4001d3 MD5 | raw file
  2Django 1.2.5 release notes
  5Welcome to Django 1.2.5!
  7This is the fifth "bugfix" release in the Django 1.2 series,
  8improving the stability and performance of the Django 1.2 codebase.
 10With four exceptions, Django 1.2.5 maintains backwards compatibility
 11with Django 1.2.4. It also contains a number of fixes and other
 12improvements. Django 1.2.5 is a recommended upgrade for any
 13development or deployment currently using or targeting Django 1.2.
 15For full details on the new features, backwards incompatibilities, and
 16deprecated features in the 1.2 branch, see the :doc:`/releases/1.2`.
 18Backwards incompatible changes
 21CSRF exception for AJAX requests
 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.
 28Prior to Django 1.2.5, our CSRF protection made an exception for AJAX
 29requests, on the following basis:
 31    * Many AJAX toolkits add an X-Requested-With header when using
 32      XMLHttpRequest.
 34    * Browsers have strict same-origin policies regarding
 35      XMLHttpRequest.
 37    * In the context of a browser, the only way that a custom header
 38      of this nature can be added is with XMLHttpRequest.
 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.
 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.
 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.
 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.
 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.
 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.
 70FileField no longer deletes files
 73In earlier Django versions, when a model instance containing a
 74:class:`~django.db.models.FileField` was deleted,
 75:class:`~django.db.models.FileField` took it upon itself to also delete the
 76file from the backend storage. This opened the door to several potentially
 77serious data-loss scenarios, including rolled-back transactions and fields on
 78different models referencing the same file. In Django 1.2.5,
 79:class:`~django.db.models.FileField` will never delete files from the backend
 80storage. If you need cleanup of orphaned files, you'll need to handle it
 81yourself (for instance, with a custom management command that can be run
 82manually or scheduled to run periodically via e.g. cron).
 84Use of custom SQL to load initial data in tests
 87Django provides a custom SQL hooks as a way to inject hand-crafted SQL
 88into the database synchronization process. One of the possible uses
 89for this custom SQL is to insert data into your database. If your
 90custom SQL contains ``INSERT`` statements, those insertions will be
 91performed every time your database is synchronized. This includes the
 92synchronization of any test databases that are created when you run a
 93test suite.
 95However, in the process of testing the Django 1.3, it was discovered
 96that this feature has never completely worked as advertised. When
 97using database backends that don't support transactions, or when using
 98a TransactionTestCase, data that has been inserted using custom SQL
 99will not be visible during the testing process.
101Unfortunately, there was no way to rectify this problem without
102introducing a backwards incompatibility. Rather than leave
103SQL-inserted initial data in an uncertain state, Django now enforces
104the policy that data inserted by custom SQL will *not* be visible
105during testing.
107This change only affects the testing process. You can still use custom
108SQL to load data into your production database as part of the syncdb
109process. If you require data to exist during test conditions, you
110should either insert it using :ref:`test fixtures
111<topics-testing-fixtures>`, or using the ``setUp()`` method of your
112test case.
114ModelAdmin.lookup_allowed signature changed
117Django 1.2.4 introduced a method ``lookup_allowed`` on ``ModelAdmin``, to cope
118with a security issue (changeset `[15033]
119<>`_). Although this method was
120never documented, it seems some people have overridden ``lookup_allowed``,
121especially to cope with regressions introduced by that changeset. While the
122method is still undocumented and not marked as stable, it may be helpful to know
123that the signature of this function has changed.