Swappable sessions

[Lorenzo Peña]

Hello fellows!

Has there ever been any discussion about making the Session model from django.contrib.sessions a swappable model? Sometimes it's required to enhance the session model in order to track more information. There are alternatives like django-user-sessions, but replacing the contrib session app doesn't feel right altogether.

Would something like this make any sense?

Thank you and stay stafe! 

[Adam Johnson]

Hi Lorenzo

Using a different Session model is already supported - see the docs: https://docs.djangoproject.com/en/3.0/topics/http/sessions/#extending-database-backed-session-engines . Or is there something beyond that which you wanted?

Thanks,

Adam

P.S. Please don't start your message addressed to "fellows" :) This mailing list has more people than the active Django fellows and many non-males ("fellow" is sometimes understood to mean males only so best to avoid :) ).

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/4c8e6811-61fc-469a-8cf5-04f30b91810b%40googlegroups.com.

--

Adam

[Lorenzo Peña]

Thanks Adam, looks like the link you posted covers it all.

[Lorenzo Peña]

Now, in order to follow the path suggested in the Django documentation for overriding database backed sessions, some of the data one might need to store in the session model is coming from the request, and Django is not passing the request when instantiating the session store.

Do you think there is a point in requesting that the request object (if available) is passed as an optional parameter when creating the session?

[Tim Graham]

Can't you copy whatever data you want from the request into the session data (request.session.<whatever> = request.<whatever>) in a view, middleware, or wherever? That seems like the proper separation of concerns.

[Lorenzo Peña]

Yes, of course. I am already working things around in order to get what I need.

Now, the database backed SessionStore defines a method "create_model_instance(self, data)" which is called from "django.contrib.sessions.middleware.SessionMiddleware". Django docs invite to redefine this method in order to populate the custom session with the required data.

My question is: would it be okay to formally ask that the request object, which is already available when the method is called, be passed to that method when called, like " create_model_instance(self, data, request=None)"? 

--
You received this message because you are subscribed to a topic in the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/DOUfhMv4T1c/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/d9eef373-28cf-4ccb-9801-90d7c38b3678%40googlegroups.com.

[Lorenzo Peña]

Yes, of course. I am already working things around in order to get what I need.

Now, the database backed SessionStore defines a method "create_model_instance(self, data)" which is called from "django.contrib.sessions.middleware.SessionMiddleware". Django docs invite to redefine this method in order to populate the custom session with the required data.

My question is: would it be okay to formally ask that the request object, which is already available there, be passed to that method when called, like " create_model_instance(self, data, request=None)"?

[Tim Graham]

I don't see a strong argument for adding it. As far as I can tell, this would require adding 'request' to the signature of SessionStore.__init___() (so it could be stored as an attribute on SessionStore and thereby available in create_model_instance()). Backwards compatibility would be non-trivial and coupling the session store to the request seems unnecessary.

[Lorenzo Peña]

Fair enough, Tim. Thanks for answering!