-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use a real SessionBase object on FooterNoSessionMiddleware #5797
Conversation
This allows all Django internals method to keep working in the same way but still using an empty session.
@@ -205,7 +206,7 @@ def process_request(self, request): | |||
settings.SESSION_COOKIE_NAME not in request.COOKIES | |||
): | |||
# Hack request.session otherwise the Authentication middleware complains. | |||
request.session = {} | |||
request.session = SessionBase() # create an empty session |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could instantiate an empty instance of the same class that we are using in the backend.
from importlib import import_module
from django.conf import settings
SessionStore = import_module(settings.SESSION_ENGINE).SessionStore
request.session = SessionStore()
I suppose that won't be any difference since the session_key
is None
, though.
I'm pretty sure this isn't the solution to our problem. We don't want a session on the request, anywhere downstream that thinks it's editing a session, that data won't be saved. We want that to error, and to stop trying to edit the session, not fake out users who think they are really editing it. |
Hrm... I implemented this solution because we are already faking it with a dict (allowing get/set values). The comment says that otherwise Auth backend fails. On the other hand, using this general Finally, for the use case I'm trying to fix solve, it will work since I'm not 100% sure, but seems to be the right way of having the "same behavior than a regular session object without saving anything and hard-failing if trying to save it". |
I know that this affects a lot of requests. So, if we are in doubt we can just go in another direction that we consider safer. Although, at some point this will bite us again. |
Good point. I mostly have 2 reservations:
So I guess I'm +0 on this proposed change, then. |
OK. I think we can merge and deploy carefully being prepared to roll it back, as you said. Although, we can have another person reviewing this before merging. |
Instead of forcing to be an empty dict
{}
, we force it to be a real SessionBase object which it's what Django uses internally. This avoid issues where other pieces expects theSessionBase
.Django docs: https://docs.djangoproject.com/en/1.11/topics/http/sessions/#django.contrib.sessions.backends.base.SessionBase