Note that the cookie is not changed every request, just the token retrieved
by the `get_token()` method (used also by the `{% csrf_token %}` tag).
While at it, made token validation strict: Where, before, any length was
accepted and non-ASCII chars were ignored, we now treat anything other than
`[A-Za-z0-9]{64}` as invalid (except for 32-char tokens, which, for
backwards-compatibility, are accepted and replaced by 64-char ones).
Thanks Trac user patrys for reporting, github user adambrenecki
for initial patch, Tim Graham for help, and Curtis Maloney,
Collin Anderson, Florian Apolloner, Markus Holtermann & Jon Dufresne
for reviews.
The check introduced in 4ce433e was too strict in real life. The poorly
implemented bots this patch attempted to ignore are sloppy when it comes
to http vs. https.
Added the CSRF_TRUSTED_ORIGINS setting which contains a list of other
domains that are included during the CSRF Referer header verification
for secure (HTTPS) requests.
Only compute the CSRF_COOKIE when it is actually used. This is a
significant speedup for clients not using cookies.
Changed result of the “test_token_node_no_csrf_cookie” test: It gets
a valid CSRF token now which seems like the correct behavior.
Changed auth_tests.test_views.LoginTest.test_login_csrf_rotate to
use get_token() to trigger CSRF cookie inclusion instead of changing
request.META["CSRF_COOKIE_USED"] directly.
This introduces a force_append_slash argument for request.get_full_path()
which is used by RedirectFallbackMiddleware and CommonMiddleware when
handling redirects for settings.APPEND_SLASH.
It prevented the GZipMiddleware from compressing some data types even on
more recent version of IE where the corresponding bug was fixed.
Thanks Aaron Cannon for the report and Tim Graham for the review.
By removing the 'supported' keyword from the detection methods and only relying
on a cached settings.LANGUAGES, the speed of said methods has been improved;
around 4x raw performance. This allows us to stop checking Python's incomplete
list of locales, and rely on a less restrictive regular expression for
accepting certain locales.
HTTP Accept-Language is defined as being case-insensitive, based on this fact
extra performance improvements have been made; it wouldn't make sense to
check for case differences.
Current language is no longer saved to session by LocaleMiddleware
on every response (the behavior introduced in #14825).
Instead language stored in session is reintroduced into new session
after logout.
Forward port of c558a43fd6 to master.
Thanks Curtis Malony and Florian Apolloner.
Squashed commit of the following:
commit 3380495e93
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Sat Nov 23 14:18:07 2013 +0100
Looked up the template_fragments cache at runtime.
commit 905a74f52b
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Sat Nov 23 14:19:48 2013 +0100
Removed all uses of create_cache.
Refactored the cache tests significantly.
Made it safe to override the CACHES setting.
commit 35e289fe92
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Sat Nov 23 12:23:57 2013 +0100
Removed create_cache function.
commit 8e274f747a
Author: Aymeric Augustin <aymeric.augustin@m4x.org>
Date: Sat Nov 23 12:04:52 2013 +0100
Updated docs to describe a simplified cache backend API.
commit ee7eb0f73e
Author: Curtis Maloney <curtis@tinbrain.net>
Date: Sat Oct 19 09:49:24 2013 +1100
Fixed#21012 -- Thread-local caches, like databases.
The old 'django_language' variable will still be read from in order
to migrate users. The backwards-compatability shim will be removed in
Django 1.8.
Thanks to jdunck for the report and stugots for the initial patch.
`HttpRequest.scheme` is `https` if `settings.SECURE_PROXY_SSL_HEADER` is
appropriately set and falls back to `HttpRequest._get_scheme()` (a hook
for subclasses to implement) otherwise.
`WSGIRequest._get_scheme()` makes use of the `wsgi.url_scheme` WSGI
environ variable to determine the request scheme.
`HttpRequest.is_secure()` simply checks if `HttpRequest.scheme` is
`https`.
This provides a way to check the current scheme in templates, for example.
It also allows us to deal with other schemes.
Thanks nslater for the suggestion.
Replaced them with per-database options, for proper multi-db support.
Also toned down the recommendation to tie transactions to HTTP requests.
Thanks Jeremy for sharing his experience.
enter_transaction_management() was nearly always followed by managed().
In three places it wasn't, but they will all be refactored eventually.
The "forced" keyword argument avoids introducing behavior changes until
then.
This is mostly backwards-compatible, except, of course, for managed
itself. There's a minor difference in _enter_transaction_management:
the top self.transaction_state now contains the new 'managed' state
rather than the previous one. Django doesn't access
self.transaction_state in _enter_transaction_management.