Thanks to Maniac for the report, julienb for the initial patch, and
especially to aaugustin for the final patch and tests.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@15696 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Introducing ability to cache HEAD requests and GET requests separately by
adding the method to the cache key while preserving the functionality that HEAD
requests can use cached reponses generated by a GET request.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@14391 bcc190cf-cafb-0310-a4f2-bffc1f526a37
All adhoc MAC applications have been updated to use HMAC, using SHA1 to
generate unique keys for each application based on the SECRET_KEY, which is
common practice for this situation. In all cases, backwards compatibility
with existing hashes has been maintained, aiming to phase this out as per
the normal deprecation process. In this way, under most normal
circumstances the old hashes will have expired (e.g. by session expiration
etc.) before they become invalid.
In the case of the messages framework and the cookie backend, which was
already using HMAC, there is the possibility of a backwards incompatibility
if the SECRET_KEY is shorter than the default 50 bytes, but the low
likelihood and low impact meant compatibility code was not worth it.
All known instances where tokens/hashes were compared using simple string
equality, which could potentially open timing based attacks, have also been
fixed using a constant-time comparison function.
There are no known practical attacks against the existing implementations,
so these security improvements will not be backported.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@14218 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Thanks to jbg for the report.
This changeset essentially backs out [13698] in favour of a method that
sanitizes the token rather than escaping it.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@13732 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This is intended to help power users who have disabled Referer headers, or
installed add-ons which have done so, and to help web site administrators
with debugging, since this problem will be browser specific and not a
programming error.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@13680 bcc190cf-cafb-0310-a4f2-bffc1f526a37
There is stub code for backwards compatiblity with Django 1.1 imports.
The documentation has been updated, but has been left in
docs/contrib/csrf.txt for now, in order to avoid dead links to
documentation on the website.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11661 bcc190cf-cafb-0310-a4f2-bffc1f526a37
In a nutshell, it's been demonstrated that this middleware can never be made reliable enough for general-purpose use, and that (despite documentation to the contrary) its inclusion in Django may lead application developers to assume that the value of ``REMOTE_ADDR`` is "safe" or in some way reliable as a source of authentication. So it's gone.
See the Django 1.1 release notes for full details, as well as upgrade instructions.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11363 bcc190cf-cafb-0310-a4f2-bffc1f526a37
In the slightly unusual case that CACHE_MIDDLEWARE_SECONDS is set to 0, don't
bother storing a copy in the local cache.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9098 bcc190cf-cafb-0310-a4f2-bffc1f526a37
when SCRIPT_NAME contains something other than '/'. Patch from jcassee.
Also fixed the middleware tests to work with this patch.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8456 bcc190cf-cafb-0310-a4f2-bffc1f526a37
CacheMiddleware itself is still around for backwards-compatibility and as a hook point for the cache decorator, but the documentation has been updated to point people towards the two-part caching middleware.
Refs #730.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8260 bcc190cf-cafb-0310-a4f2-bffc1f526a37
We now have automatic HEAD processing always (previously required ConditionalGetMiddleware), middleware benefits from the Location header rewrite, so they can use relative URLs as well, and responses with response codes 1xx, 204 or 304 will always have their content removed, in accordance with the HTTP spec (so it's much harder to indavertently deliver invalid responses).
Based on a patch and diagnosis from regexbot@gmail.com.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@6662 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Jannis Leidel
Luke Plant
Carl Meyer
Alex Gaynor
Russell Keith-Magee
Honza Král
James Bennett
Karen Tracey
Adrian Holovaty
Jacob Kaplan-Moss
Malcolm Tredinnick
Gary Wilson Jr