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.
These tests are expected to fail for the file session backend because it
doesn't handle expiry properly. They didn't because of an error in the
test setup sequence.
Refs #19200, #18194.
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).
Some backends issue a warning here, others not. This is not the primary
goal of the test, so the assertion about the warning has been removed.
Thanks Carl Meyer for noticing the issue and suggesting the fix.
* 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.
Saving session data is somewhat likely to lead into error when the
status code is 500. It is guaranteed to lead into error if the reason
for the 500 code is query error on PostgreSQL.
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