{% endif %}
diff --git a/django/contrib/gis/gdal/libgdal.py b/django/contrib/gis/gdal/libgdal.py
index 6589c5647c..a7a5658c49 100644
--- a/django/contrib/gis/gdal/libgdal.py
+++ b/django/contrib/gis/gdal/libgdal.py
@@ -14,10 +14,10 @@ if lib_path:
lib_names = None
elif os.name == 'nt':
# Windows NT shared library
- lib_names = ['gdal16', 'gdal15']
+ lib_names = ['gdal17', 'gdal16', 'gdal15']
elif os.name == 'posix':
# *NIX library names.
- lib_names = ['gdal', 'GDAL', 'gdal1.6.0', 'gdal1.5.0', 'gdal1.4.0']
+ lib_names = ['gdal', 'GDAL', 'gdal1.7.0', 'gdal1.6.0', 'gdal1.5.0', 'gdal1.4.0']
else:
raise OGRException('Unsupported OS "%s"' % os.name)
diff --git a/django/middleware/csrf.py b/django/middleware/csrf.py
index 10fab290c9..2fdfdbc9e3 100644
--- a/django/middleware/csrf.py
+++ b/django/middleware/csrf.py
@@ -126,13 +126,27 @@ class CsrfViewMiddleware(object):
return accept()
if request.is_secure():
- # Strict referer checking for HTTPS
+ # Suppose user visits http://example.com/
+ # An active network attacker,(man-in-the-middle, MITM) sends a
+ # POST form which targets https://example.com/detonate-bomb/ and
+ # submits it via javascript.
+ #
+ # The attacker will need to provide a CSRF cookie and token, but
+ # that is no problem for a MITM and the session independent
+ # nonce we are using. So the MITM can circumvent the CSRF
+ # protection. This is true for any HTTP connection, but anyone
+ # using HTTPS expects better! For this reason, for
+ # https://example.com/ we need additional protection that treats
+ # http://example.com/ as completely untrusted. Under HTTPS,
+ # Barth et al. found that the Referer header is missing for
+ # same-domain requests in only about 0.2% of cases or less, so
+ # we can use strict Referer checking.
referer = request.META.get('HTTP_REFERER')
if referer is None:
return reject("Referer checking failed - no Referer.")
# The following check ensures that the referer is HTTPS,
- # the domains match and the ports match. This might be too strict.
+ # the domains match and the ports match - the same origin policy.
good_referer = 'https://%s/' % request.get_host()
if not referer.startswith(good_referer):
return reject("Referer checking failed - %s does not match %s." %
diff --git a/docs/faq/install.txt b/docs/faq/install.txt
index f20b2bc187..0139a82a67 100644
--- a/docs/faq/install.txt
+++ b/docs/faq/install.txt
@@ -46,7 +46,7 @@ Do I lose anything by using Python 2.4 versus newer Python versions, such as Pyt
-----------------------------------------------------------------------------------------------
Not in the core framework. Currently, Django itself officially supports any
-version of Python from 2.4 through 2.6, inclusive. However, newer versions of
+version of Python from 2.4 through 2.7, inclusive. However, newer versions of
Python are often faster, have more features, and are better supported.
Third-party applications for use with Django are, of course, free to set their
own version requirements.
@@ -56,7 +56,7 @@ versions as part of a migration which will end with Django running on Python 3
(see below for details).
All else being equal, we recommend that you use the latest 2.x release
-(currently Python 2.6). This will let you take advantage of the numerous
+(currently Python 2.7). This will let you take advantage of the numerous
improvements and optimizations to the Python language since version 2.4, and
will help ease the process of dropping support for older Python versions on
the road to Python 3.
diff --git a/docs/intro/install.txt b/docs/intro/install.txt
index 901bde01c2..dcb9c8e0c4 100644
--- a/docs/intro/install.txt
+++ b/docs/intro/install.txt
@@ -12,7 +12,7 @@ Install Python
--------------
Being a Python Web framework, Django requires Python. It works with any Python
-version from 2.4 to 2.6 (due to backwards
+version from 2.4 to 2.7 (due to backwards
incompatibilities in Python 3.0, Django does not currently work with
Python 3.0; see :ref:`the Django FAQ ` for more
information on supported Python versions and the 3.0 transition), but we recommend installing Python 2.5 or later. If you do so, you won't need to set up a database just yet: Python 2.5 or later includes a lightweight database called SQLite_.
diff --git a/docs/ref/contrib/gis/create_template_postgis-1.4.sh b/docs/ref/contrib/gis/create_template_postgis-1.4.sh
index 74a6ef98d2..57a1373f96 100755
--- a/docs/ref/contrib/gis/create_template_postgis-1.4.sh
+++ b/docs/ref/contrib/gis/create_template_postgis-1.4.sh
@@ -1,5 +1,5 @@
#!/usr/bin/env bash
-POSTGIS_SQL_PATH=`pg_config --sharedir`/contrib/postgis-1.4
+POSTGIS_SQL_PATH=`pg_config --sharedir`/contrib
createdb -E UTF8 template_postgis # Create the template spatial database.
createlang -d template_postgis plpgsql # Adding PLPGSQL language support.
psql -d postgres -c "UPDATE pg_database SET datistemplate='true' WHERE datname='template_postgis';"
diff --git a/docs/ref/contrib/gis/install.txt b/docs/ref/contrib/gis/install.txt
index 00d4e62e9f..0b7954336c 100644
--- a/docs/ref/contrib/gis/install.txt
+++ b/docs/ref/contrib/gis/install.txt
@@ -383,9 +383,9 @@ Typically, SQLite packages are not compiled to include the `R*Tree module`__ --
thus it must be compiled from source. First download the latest amalgamation
source archive from the `SQLite download page`__, and extract::
- $ wget http://www.sqlite.org/sqlite-amalgamation-3.6.22.tar.gz
- $ tar xzf sqlite-amalgamation-3.6.22.tar.gz
- $ cd sqlite-3.6.22
+ $ wget http://sqlite.org/sqlite-amalgamation-3.6.23.1.tar.gz
+ $ tar xzf sqlite-amalgamation-3.6.23.1.tar.gz
+ $ cd sqlite-3.6.23.1
Next, run the ``configure`` script -- however the ``CFLAGS`` environment variable
needs to be customized so that SQLite knows to build the R*Tree module::
@@ -449,12 +449,9 @@ Finally, do the same for the SpatiaLite tools::
.. note::
For Mac OS X users building from source, the SpatiaLite library *and* tools
- need to be linked into the existing ``iconv`` library. While this happens
- automatically on Linux, the ``configure`` scripts need to know about the
- specific location on Mac OS X (via modification of the ``CFLAGS`` and
- ``LDFLAGS`` environment variables prior to configuration)::
+ need to have their ``target`` configured::
- $ CFLAGS=-I/usr/include LDFLAGS="-L/usr/lib -liconv" ./configure
+ $ ./configure --target=macosx
__ http://www.gaia-gis.it/spatialite/sources.html
@@ -804,8 +801,8 @@ your ``.profile`` to be able to run the package programs from the command-line::
export PATH=/Library/Frameworks/GDAL.framework/Programs:$PATH
export PATH=/usr/local/pgsql/bin:$PATH
-__ http://www.kyngchaos.com/wiki/software:frameworks
-__ http://www.kyngchaos.com/wiki/software:postgres
+__ http://www.kyngchaos.com/software/frameworks
+__ http://www.kyngchaos.com/software/postgres
.. note::
diff --git a/docs/ref/validators.txt b/docs/ref/validators.txt
index bbba84c7f9..916c388f08 100644
--- a/docs/ref/validators.txt
+++ b/docs/ref/validators.txt
@@ -5,6 +5,8 @@ Validators
==========
.. versionadded:: 1.2
+.. module:: django.core.validators
+ :synopsis: Validation utilities and base classes
Writing validators
==================
diff --git a/docs/topics/auth.txt b/docs/topics/auth.txt
index 4e07f73190..eae07ed717 100644
--- a/docs/topics/auth.txt
+++ b/docs/topics/auth.txt
@@ -435,8 +435,6 @@ Anonymous users
instead of ``False``.
* :meth:`~django.contrib.auth.models.User.is_authenticated()` returns
``False`` instead of ``True``.
- * :meth:`~django.contrib.auth.models.User.has_perm()` always returns
- ``False``.
* :meth:`~django.contrib.auth.models.User.set_password()`,
:meth:`~django.contrib.auth.models.User.check_password()`,
:meth:`~django.contrib.auth.models.User.save()`,
diff --git a/docs/topics/db/optimization.txt b/docs/topics/db/optimization.txt
index 6063bc6c2a..5d74fc9ce9 100644
--- a/docs/topics/db/optimization.txt
+++ b/docs/topics/db/optimization.txt
@@ -5,7 +5,7 @@ Database access optimization
============================
Django's database layer provides various ways to help developers get the most
-out of their databases. This documents gathers together links to the relevant
+out of their databases. This document gathers together links to the relevant
documentation, and adds various tips, organized under an number of headings that
outline the steps to take when attempting to optimize your database usage.
@@ -108,9 +108,8 @@ Do database work in the database rather than in Python
For instance:
-* At the most basic level, use :ref:`filter and exclude ` to
- filtering in the database to avoid loading data into your Python process, only
- to throw much of it away.
+* At the most basic level, use :ref:`filter and exclude ` to do
+ filtering in the database.
* Use :ref:`F() object query expressions ` to do filtering
against other fields within the same model.
@@ -245,9 +244,6 @@ methods of individual instances, which means that any custom behaviour you have
added for these methods will not be executed, including anything driven from the
normal database object :ref:`signals `.
-Don't retrieve things you already have
-======================================
-
Use foreign key values directly
-------------------------------
diff --git a/docs/topics/install.txt b/docs/topics/install.txt
index d53f49de46..2147a98931 100644
--- a/docs/topics/install.txt
+++ b/docs/topics/install.txt
@@ -11,7 +11,7 @@ Install Python
Being a Python Web framework, Django requires Python.
-It works with any Python version from 2.4 to 2.6 (due to backwards
+It works with any Python version from 2.4 to 2.7 (due to backwards
incompatibilities in Python 3.0, Django does not currently work with
Python 3.0; see :ref:`the Django FAQ ` for more
information on supported Python versions and the 3.0 transition).
diff --git a/docs/topics/serialization.txt b/docs/topics/serialization.txt
index 1cf8e86462..c5155107f0 100644
--- a/docs/topics/serialization.txt
+++ b/docs/topics/serialization.txt
@@ -169,7 +169,7 @@ For example::
json_serializer.serialize(queryset, ensure_ascii=False, stream=response)
The Django source code includes the simplejson_ module. However, if you're
-using Python 2.6 (which includes a builtin version of the module), Django will
+using Python 2.6 or later (which includes a builtin version of the module), Django will
use the builtin ``json`` module automatically. If you have a system installed
version that includes the C-based speedup extension, or your system version is
more recent than the version shipped with Django (currently, 2.0.7), the
diff --git a/tests/regressiontests/m2m_through_regress/tests.py b/tests/regressiontests/m2m_through_regress/tests.py
index ff1d95020e..406851acfd 100644
--- a/tests/regressiontests/m2m_through_regress/tests.py
+++ b/tests/regressiontests/m2m_through_regress/tests.py
@@ -66,11 +66,13 @@ class M2MThroughTestCase(TestCase):
p = Person.objects.create(name="Bob")
g = Group.objects.create(name="Roll")
- Membership.objects.create(person=p, group=g)
+ m =Membership.objects.create(person=p, group=g)
+
+ pks = {"p_pk": p.pk, "g_pk": g.pk, "m_pk": m.pk}
out = StringIO()
management.call_command("dumpdata", "m2m_through_regress", format="json", stdout=out)
- self.assertEqual(out.getvalue().strip(), """[{"pk": 1, "model": "m2m_through_regress.membership", "fields": {"person": 1, "price": 100, "group": 1}}, {"pk": 1, "model": "m2m_through_regress.person", "fields": {"name": "Bob"}}, {"pk": 1, "model": "m2m_through_regress.group", "fields": {"name": "Roll"}}]""")
+ self.assertEqual(out.getvalue().strip(), """[{"pk": %(m_pk)s, "model": "m2m_through_regress.membership", "fields": {"person": %(p_pk)s, "price": 100, "group": %(g_pk)s}}, {"pk": %(p_pk)s, "model": "m2m_through_regress.person", "fields": {"name": "Bob"}}, {"pk": %(g_pk)s, "model": "m2m_through_regress.group", "fields": {"name": "Roll"}}]""" % pks)
out = StringIO()
management.call_command("dumpdata", "m2m_through_regress", format="xml",
@@ -78,19 +80,19 @@ class M2MThroughTestCase(TestCase):
self.assertEqual(out.getvalue().strip(), """
-
- """.strip())
+ """.strip() % pks)
def test_join_trimming(self):
"Check that we don't involve too many copies of the intermediate table when doing a join. Refs #8046, #8254"