diff --git a/django/contrib/gis/tests/relatedapp/tests.py b/django/contrib/gis/tests/relatedapp/tests.py index 2bdf29304d..0e905274d4 100644 --- a/django/contrib/gis/tests/relatedapp/tests.py +++ b/django/contrib/gis/tests/relatedapp/tests.py @@ -279,11 +279,11 @@ class RelatedGeoModelTest(unittest.TestCase): def test14_collect(self): "Testing the `collect` GeoQuerySet method and `Collect` aggregate." # Reference query: - # SELECT AsText(ST_Collect("relatedapp_location"."point")) FROM "relatedapp_city" LEFT OUTER JOIN - # "relatedapp_location" ON ("relatedapp_city"."location_id" = "relatedapp_location"."id") + # SELECT AsText(ST_Collect("relatedapp_location"."point")) FROM "relatedapp_city" LEFT OUTER JOIN + # "relatedapp_location" ON ("relatedapp_city"."location_id" = "relatedapp_location"."id") # WHERE "relatedapp_city"."state" = 'TX'; ref_geom = fromstr('MULTIPOINT(-97.516111 33.058333,-96.801611 32.782057,-95.363151 29.763374,-96.801611 32.782057)') - + c1 = City.objects.filter(state='TX').collect(field_name='location__point') c2 = City.objects.filter(state='TX').aggregate(Collect('location__point'))['location__point__collect'] @@ -293,7 +293,6 @@ class RelatedGeoModelTest(unittest.TestCase): self.assertEqual(4, len(coll)) self.assertEqual(ref_geom, coll) - # TODO: Related tests for KML, GML, and distance lookups. def suite(): diff --git a/docs/index.txt b/docs/index.txt index 2c868f275f..12d93526ae 100644 --- a/docs/index.txt +++ b/docs/index.txt @@ -202,5 +202,5 @@ The Django open-source project * **Django over time:** :ref:`API stability ` | - :ref:`Release notes ` | + :ref:`Release notes and upgrading instructions ` | :ref:`Deprecation Timeline ` diff --git a/docs/ref/contrib/csrf.txt b/docs/ref/contrib/csrf.txt index c1bdb59cd1..b76ec2f4f0 100644 --- a/docs/ref/contrib/csrf.txt +++ b/docs/ref/contrib/csrf.txt @@ -46,7 +46,7 @@ To enable CSRF protection for your views, follow these steps: ``django.views.decorators.csrf.csrf_protect`` on particular views you want to protect (see below). - 2. In any template that uses a POST form, use the ``csrf_token`` tag inside + 2. In any template that uses a POST form, use the :ttag:`csrf_token` tag inside the ``
`` element if the form is for an internal URL, e.g.:: {% csrf_token %} @@ -123,14 +123,14 @@ as ``CsrfResponseMiddleware``, and it can be used by following these steps: ``CsrfResponseMiddleware`` needs to process the response before things like compression or setting ofETags happen to the response, so it must - come after ``GZipMiddleware``, ``CommonMiddleware`` and + come after ``GZipMiddleware``, ``CommonMiddleware`` and ``ConditionalGetMiddleware`` in the list. It also must come after ``CsrfViewMiddleware``. Use of the ``CsrfResponseMiddleware`` is not recommended because of the performance hit it imposes, and because of a potential security problem (see below). It can be used as an interim measure until applications have been -updated to use the ``{% csrf_token %}`` tag. It is deprecated and will be +updated to use the :ttag:`csrf_token` tag. It is deprecated and will be removed in Django 1.4. Django 1.1 and earlier provided a single ``CsrfMiddleware`` class. This is also @@ -199,7 +199,7 @@ Note that contrib apps, such as the admin, have been updated to use the ``CsrfViewMiddleware`` to your settings. However, if you have supplied customised templates to any of the view functions of contrib apps (whether explicitly via a keyword argument, or by overriding built-in templates), **you -MUST update them** to include the ``csrf_token`` template tag as described +MUST update them** to include the :ttag:`csrf_token` template tag as described above, or they will stop working. (If you cannot update these templates for some reason, you will be forced to use ``CsrfResponseMiddleware`` for these views to continue working). @@ -364,7 +364,7 @@ exactly that. Caching ======= -If the ``csrf_token`` template tag is used by a template (or the ``get_token`` +If the :ttag:`csrf_token` template tag is used by a template (or the ``get_token`` function is called some other way), ``CsrfViewMiddleware`` will add a cookie and a ``Vary: Cookie`` header to the response. Similarly, ``CsrfResponseMiddleware`` will send the ``Vary: Cookie`` header if it inserted diff --git a/docs/ref/databases.txt b/docs/ref/databases.txt index c4052a50b5..ec47fbb1a9 100644 --- a/docs/ref/databases.txt +++ b/docs/ref/databases.txt @@ -256,7 +256,6 @@ Here's a sample configuration which uses a MySQL option file:: } } - # my.cnf [client] database = DATABASE_NAME diff --git a/docs/ref/django-admin.txt b/docs/ref/django-admin.txt index 71f54b4276..9ff41faa4d 100644 --- a/docs/ref/django-admin.txt +++ b/docs/ref/django-admin.txt @@ -470,6 +470,11 @@ prompts. The alias for the database to reset. By default resets all databases. +Executes the equivalent of ``sqlreset`` for the given app name(s). + +The :djadminopt:`--noinput` option may be provided to suppress all user +prompts. + runfcgi [options] ----------------- diff --git a/docs/ref/settings.txt b/docs/ref/settings.txt index c91198d75b..a2c4e54363 100644 --- a/docs/ref/settings.txt +++ b/docs/ref/settings.txt @@ -190,7 +190,6 @@ end users) indicating the reason the request was rejected. See :ref:`ref-contrib-csrf`. - .. setting:: DATABASES DATABASES diff --git a/docs/ref/templates/builtins.txt b/docs/ref/templates/builtins.txt index 8266224c39..20591311be 100644 --- a/docs/ref/templates/builtins.txt +++ b/docs/ref/templates/builtins.txt @@ -51,6 +51,18 @@ comment Ignore everything between ``{% comment %}`` and ``{% endcomment %}`` +.. templatetag:: csrf_token + +csrf_token +~~~~~~~~~~ + +.. versionadded:: 1.1.2 + +In the Django 1.1.X series, this is a no-op tag that returns an empty string for +future compatibility purposes. In Django 1.2 and later, it is used for CSRF +protection, as described in the documentation for :ref:`Cross Site Request +Forgeries `. + .. templatetag:: cycle csrf_token diff --git a/docs/releases/1.1.2.txt b/docs/releases/1.1.2.txt new file mode 100644 index 0000000000..64bbdd5dde --- /dev/null +++ b/docs/releases/1.1.2.txt @@ -0,0 +1,36 @@ +.. _releases-1.1.2: + +============================================== +Django 1.1.2 release notes — UNDER DEVELOPMENT +============================================== + +This page documents release notes for the as-yet-unreleased Django +1.1.2. As such it is tentative and subject to change. It provides +up-to-date information for those who are following the 1.1.X branch. + +This is the second "bugfix" release in the Django 1.1 series, +improving the stability and performance of the Django 1.1 codebase. + +Django 1.1.2 maintains backwards compatibility with Django +1.1.0, but contain a number of fixes and other +improvements. Django 1.1.2 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 :ref:`releases-1.1`. + +One new feature +--------------- + +Ordinarily, a point release would not include new features, but in the +case of Django 1.1.2, we have made an exception to this rule. Django +1.2 (the next major release of Django) will contain a feature that +will improve protection against Cross-Site Request Forgery (CSRF) +attacks. This feature requires the use of a new :ttag:`csrf_token` +template tag in all forms that Django renders. + +To make it easier to support both 1.1.X and 1.2.X versions of Django with +the same templates, we have decided to introduce the :ttag:`csrf_token` template +tag to the 1.1.X branch. In the 1.1.X branch, :ttag:`csrf_token` does nothing - +it has no effect on templates or form processing. However, it means that the +same template will work with Django 1.2. diff --git a/docs/releases/1.2.txt b/docs/releases/1.2.txt index f67588926c..afc2657786 100644 --- a/docs/releases/1.2.txt +++ b/docs/releases/1.2.txt @@ -8,6 +8,11 @@ This page documents release notes for the as-yet-unreleased Django 1.2. As such it is tentative and subject to change. It provides up-to-date information for those who are following trunk. +Django 1.2 includes a number of nifty `new features`_, lots of bug +fixes, and an easy upgrade path from Django 1.1. + +.. _new features: `What's new in Django 1.2`_ + .. _backwards-incompatible-changes-1.2: Backwards-incompatible changes in 1.2 @@ -68,3 +73,37 @@ Features deprecated in 1.2 ========================== None. + +What's new in Django 1.2 +======================== + +CSRF support +------------ + +Django now has much improved protection against :ref:`Cross-Site +Request Forgery (CSRF) attacks`. This type of attack +occurs when a malicious Web site contains a link, a form button or +some javascript that is intended to perform some action on your Web +site, using the credentials of a logged-in user who visits the +malicious site in their browser. A related type of attack, 'login +CSRF', where an attacking site tricks a user's browser into logging +into a site with someone else's credentials, is also covered. + +Email Backends +-------------- + +You can now :ref:`configure the way that Django sends email +`. Instead of using SMTP to send all email, you +can now choose a configurable email backend to send messages. If your +hosting provider uses a sandbox or some other non-SMTP technique for +sending mail, you can now construct an email backend that will allow +Django's standard :ref:`mail sending methods` to use +those facilities. + +This also makes it easier to debug mail sending - Django ships with +backend implementations that allow you to send email to a +:ref:`file`, to the +:ref:`console`, or to +:ref:`memory` - you can even configure all +email to be :ref:`thrown away`. + diff --git a/docs/releases/index.txt b/docs/releases/index.txt index 7b0f30e9a2..868ff5bd63 100644 --- a/docs/releases/index.txt +++ b/docs/releases/index.txt @@ -1,5 +1,6 @@ .. _releases-index: +============= Release notes ============= @@ -7,37 +8,60 @@ Release notes for the official Django releases. Each release note will tell you what's new in each version, and will also describe any backwards-incompatible changes made in that version. +For those upgrading to a new version of Django, you will need to check +all the backwards-incompatible changes and deprecated features for +each 'final' release from the one after your current Django version, +up to and including the new version. + +Final releases +============== + +1.2 release +----------- .. toctree:: :maxdepth: 1 - 0.95 - 0.96 - 1.0-alpha-1 - 1.0-alpha-2 - 1.0-beta - 1.0-beta-2 - 1.0 - 1.0.1 - 1.0.2 - 1.1-alpha-1 - 1.1-beta-1 - 1.1-rc-1 + 1.2 + +1.1 release +----------- +.. toctree:: + :maxdepth: 1 + + 1.1.2 1.1 -Upgrading -========= +1.0 release +----------- +.. toctree:: + :maxdepth: 1 -For those upgrading to a new version of Django, you will need to check all the -backwards-incompatible changes and deprecated features for each 'final' release -from the one after your old version up to and including your new version. The -relevant sections of the release notes are linked below below for your -convenience. + 1.0.2 + 1.0.1 + 1.0 -For those following trunk, the tentative release notes for the next version to -be released are also included at the bottom. This is kept up to date with new -features and changes that you need to be aware of. +Pre-1.0 releases +---------------- +.. toctree:: + :maxdepth: 1 - * :ref:`backwards-incompatible-changes-1.1` - * :ref:`deprecated-features-1.1` - * :ref:`backwards-incompatible-changes-1.2` - * :ref:`deprecated-features-1.2` + 0.96 + 0.95 + +Development releases +==================== + +These notes are retained for historical purposes. If you are upgrading +between formal Django releases, you don't need to worry about these +notes. + +.. toctree:: + :maxdepth: 1 + + 1.1-rc-1 + 1.1-beta-1 + 1.1-alpha-1 + 1.0-beta-2 + 1.0-beta + 1.0-alpha-2 + 1.0-alpha-1 diff --git a/docs/topics/email.txt b/docs/topics/email.txt index 92e3c0263d..f7857479ca 100644 --- a/docs/topics/email.txt +++ b/docs/topics/email.txt @@ -421,6 +421,8 @@ want to specify it explicitly, put the following in your settings:: still available in ``django.core.mail`` as an alias for the SMTP backend. New code should use :meth:`~django.core.mail.get_connection` instead. +.. _topic-email-console-backend: + Console backend ~~~~~~~~~~~~~~~ @@ -436,6 +438,8 @@ To specify this backend, put the following in your settings:: This backend is not intended for use in production -- it is provided as a convenience that can be used during development. +.. _topic-email-file-backend: + File backend ~~~~~~~~~~~~ @@ -453,6 +457,8 @@ To specify this backend, put the following in your settings:: This backend is not intended for use in production -- it is provided as a convenience that can be used during development. +.. _topic-email-memory-backend: + In-memory backend ~~~~~~~~~~~~~~~~~ @@ -469,6 +475,8 @@ To specify this backend, put the following in your settings:: This backend is not intended for use in production -- it is provided as a convenience that can be used during development and testing. +.. _topic-email-dummy-backend: + Dummy backend ~~~~~~~~~~~~~ diff --git a/tests/regressiontests/backends/tests.py b/tests/regressiontests/backends/tests.py index c6ed025a90..0735ce193e 100644 --- a/tests/regressiontests/backends/tests.py +++ b/tests/regressiontests/backends/tests.py @@ -18,6 +18,21 @@ class Callproc(unittest.TestCase): return True else: return True + +class LongString(unittest.TestCase): + + def test_long_string(self): + # If the backend is Oracle, test that we can save a text longer + # than 4000 chars and read it properly + if settings.DATABASE_ENGINE == 'oracle': + c = connection.cursor() + c.execute('CREATE TABLE ltext ("TEXT" NCLOB)') + long_str = ''.join([unicode(x) for x in xrange(4000)]) + c.execute('INSERT INTO ltext VALUES (%s)',[long_str]) + c.execute('SELECT text FROM ltext') + row = c.fetchone() + c.execute('DROP TABLE ltext') + self.assertEquals(long_str, row[0].read()) class LongString(unittest.TestCase):