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
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
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
Aymeric Augustin
Jannis Leidel
Paul McMillan
Russell Keith-Magee
Malcolm Tredinnick
Adrian Holovaty
Gary Wilson Jr
Jacob Kaplan-Moss