Password prompt response can get cached
dpoirier opened this issue · comments
We recently enabled a caching engine on a site and starting having problems where lockdown's password prompt would keep getting displayed even after entering a valid password.
I believe this was due to Django's caching middleware caching the response from lockdown.
I'm working around it by putting the lockdown middleware just after the session middleware in MIDDLEWARE_CLASSES instead of at the end, but it would probably be better if the response headers when lockdown prompts for a password were to indicate that the response should never be cached.
Thanks for reporting that issue. I'll try to have a look into it during the next days.
Hi Dan,
I tried to reproduce the behavior with a clean Django project with activated side-wide caching using Djangos caching middleware, but wasn't able to reproduce the behavior. Can you please add some details about your setup, which might help to reproduce this issue?
Hi Dan,
anything new regarding the problem? It'd be really great if you could provide some additional information about the environment as I'm not able to reproduce it.
Have you tried putting the django-lockdown middleware at the end of MIDDLEWARE_CLASSES, where we had it? We haven't seen the problem since moving it to immediately after the session middleware, before the cache fetch middleware.
I just tried it once again with the lockdown.middleware.LockdownMiddleware after django.middleware.cache.FetchFromCacheMiddleware, but I'm still unable to reproduce this problem.
Also please mind that no other middleware should be placed after the django.middleware.cache.FetchFromCacheMiddleware anyway:
No, that’s not a typo: the “update” middleware must be first in the list, and the “fetch” middleware must be last. The details are a bit obscure, but see Order of MIDDLEWARE below if you’d like the full story.
https://docs.djangoproject.com/en/1.10/topics/cache/#the-per-site-cache
If you can provide me with a reliable way to reproduce the problem, I'm glad to look for a solution, otherwise I'll have to close this issue, as I simply can't reproduce it.
Sorry, I have not had time to try to reproduce it locally. After
rearranging our own middleware settings, we haven't seen it again anyway.
_Dan Poirier_Django Developer
dpoirier@caktusgroup.com
www.caktusgroup.com
On Tue, Oct 25, 2016 at 3:34 AM, Daniel Roschka notifications@github.com
wrote:
I just tried it once again with the lockdown.middleware.LockdownMiddleware
after django.middleware.cache.FetchFromCacheMiddleware, but I'm still
unable to reproduce this problem.
Also please mind that no other middleware should be placed after the
django.middleware.cache.FetchFromCacheMiddleware anyway:No, that’s not a typo: the “update” middleware must be first in the list,
and the “fetch” middleware must be last. The details are a bit obscure, but
see Order of MIDDLEWARE below if you’d like the full story.https://docs.djangoproject.com/en/1.10/topics/cache/#the-per-site-cache
If you can provide me with a reliable way to reproduce the problem, I'm
glad to look for a solution, otherwise I'll have to close this issue, as I
simply can't reproduce it.—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#9 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACqNRyZ1vvtHXgkcVE6ncYxrdGaiVDUqks5q3bDrgaJpZM4J5Ekn
.
Closed as not reproducible for now. If somebody is able to reproduce it, I'm happy to re-open this issue again.