From 2fa77d9d543a4eaa7c97250816543909965da747 Mon Sep 17 00:00:00 2001 From: Tim Abbott Date: Fri, 16 Nov 2018 12:01:15 -0800 Subject: [PATCH] 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). --- zproject/settings.py | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/zproject/settings.py b/zproject/settings.py index 82765af4b2..1768360d95 100644 --- a/zproject/settings.py +++ b/zproject/settings.py @@ -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.