sessions: Stop using the cached_db sessions engine.

See https://github.com/zulip/zulip/issues/10856 for details on the bug
here; but basically, users who reset their password were unable to
login until the next time we flushed memcached.  The issue disappeared
after stopping using the Django cached_db session engine, so it's
pretty clear that some sort of bug with that session engine
interacting with our password reset logic is the root cause.

Further debugging is required to understand this fully, but for now,
it seems wise to just disable the backend.

The cost of doing so is a small performance decrease, which is likely
acceptable until we can resolve this (it's certainly a more minor
problem than the "Can't login" bug that disabling this removes).
This commit is contained in:
Tim Abbott 2018-11-16 12:01:15 -08:00
parent ededdc512b
commit 2fa77d9d54
1 changed files with 3 additions and 1 deletions

View File

@ -650,7 +650,9 @@ RABBITMQ_PASSWORD = get_secret("rabbitmq_password")
# CACHING CONFIGURATION
########################################################################
SESSION_ENGINE = "django.contrib.sessions.backends.cached_db"
# TODO: Restore this to django.contrib.sessions.backends.cached_db
# after debugging; see https://github.com/zulip/zulip/issues/10856 for details.
SESSION_ENGINE = "django.contrib.sessions.backends.db"
# Compress large values being stored in memcached; this is important
# for at least the realm_users cache.