Added settings.SESSION_SERIALIZER which is the import path of a serializer
to use for sessions.
Thanks apollo13, carljm, shaib, akaariai, charettes, and dstufft for reviews.
SuspiciousOperations have been differentiated into subclasses, and
are now logged to a 'django.security.*' logger. SuspiciousOperations
that reach django.core.handlers.base.BaseHandler will now return a 400
instead of a 500.
Thanks to tiwoc for the report, and Carl Meyer and Donald Stufft
for review.
Since "unless managed" now means "if database-level autocommit",
committing or rolling back doesn't have any effect.
Restored transactional integrity in a few places that relied on
automatically-started transactions with a transitory API.
* Prevented stale session files from being loaded
* Added removal of stale session files in django-admin.py clearsessions
Thanks ej for the report, crodjer and Elvard for their inputs.
This change allows for cleaner tests: we can test the exact output.
Refs #18194: this change makes it possible to compute session expiry
dates at times other than when the session is saved.
Fixed#18458: the existence of the `modification` kwarg implies that you
must pass it to get_expiry_age/date if you call these functions outside
of a short request - response cycle (the intended use case).
* Renamed smart_unicode to smart_text (but kept the old name under
Python 2 for backwards compatibility).
* Renamed smart_str to smart_bytes.
* Re-introduced smart_str as an alias for smart_text under Python 3
and smart_bytes under Python 2 (which is backwards compatible).
Thus smart_str always returns a str objects.
* Used the new smart_str in a few places where both Python 2 and 3
want a str.
The previous commit didn't work with PyLibMC.
This solution appears to be the best compromise
at this point in the 1.4 release cycle.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@17797 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Catches memcached session key errors related to overly long session keys.
This is a long-standing bug, but severity was exacerbated by the addition
of cookie-backed session storage, which generates long session values. If
an installation switched from cookie-backed session store to memcached,
users would not be able to log in because of the server error from overly
long memcached keys.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@17795 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Removes several ad hoc implementations of get_random_string()
and removes an innapropriate use of settings.SECRET_KEY.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@17580 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This also removes the implicit initialization of the session key on the first access in favor of explicit initialization.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@17155 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
Also made the FileSession backend consistent with other backends in one
corner case uncovered by the conversion, namely that the backend should
create a new key if the one passed in is invalid.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@13482 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This monster of a patch is the result of Alex Gaynor's 2009 Google Summer of Code project.
Congratulations to Alex for a job well done.
Big thanks also go to:
* Justin Bronn for keeping GIS in line with the changes,
* Karen Tracey and Jani Tiainen for their help testing Oracle support
* Brett Hoerner, Jon Loyens, and Craig Kimmerer for their feedback.
* Malcolm Treddinick for his guidance during the GSoC submission process.
* Simon Willison for driving the original design process
* Cal Henderson for complaining about ponies he wanted.
... and everyone else too numerous to mention that helped to bring this feature into fruition.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11952 bcc190cf-cafb-0310-a4f2-bffc1f526a37
because some configurations of MySQL (with utf8_bin collation) will return
bytestring, rather than unicode data, which was causing problems previously.
Refs #8340.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8507 bcc190cf-cafb-0310-a4f2-bffc1f526a37
sesssion. This means the user will see their session preserved across a login
boundary, but somebody snooping the anonymous session key won't be able to view
the authenticated session data.
This is the final piece of the session key handling changes.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8459 bcc190cf-cafb-0310-a4f2-bffc1f526a37
a cookie) with no corresponding entry in the database.
This only affected the database backend, but I've applied the same fix to all
three backends for robustness.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8351 bcc190cf-cafb-0310-a4f2-bffc1f526a37
regenerates the key. Used to ensure the caller gets a fresh session at logout,
for example.
Based on a patch from mrts. Refs #7515.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8342 bcc190cf-cafb-0310-a4f2-bffc1f526a37
incompatible for custom session backends.
Whilst we were in the neighbourhood, use a larger range of session key values
to save a small amount of time and use the hardware-base random numbers where
available (transparently falls back to pseudo-RNG otherwise).
Fixed#1080
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8340 bcc190cf-cafb-0310-a4f2-bffc1f526a37