Use new Session model as a SessionBackend? about django-allauth HOT 4 CLOSED

The purpose of the UserSession model is to be able to keep track of all the sessions a user has running. A UserSession instance itself does not represent a session, it is merely a pointer to an actual session. As it is not a session, it cannot replace the builtin Session model. Note that the builtin Session model is not at all aware of users, it is just a data payload pointed to by a session cookie, and there may or may not be a user attached to that session. The sessions app itself is not aware of users at all. All in all, I do not see a way of unifying this.

Could you elaborate a bit on potential problems you see, especially curious about the "cleaner implementation" bit.

from django-allauth.

@pennersr Fair enough, I just often end up using django-user-sessions which brings in a custom SessionEngine linking User to Session.

It's just a cleaner implementation using the swappable session model rather than creating the extra UserSession instance. Since Django allows for swapping in a different session backend, it seems like it would be cleaner to implement UserSession as a better session backend (rather than creating extra writes to the DB and extra joins with the separate model).

From taking a quick look, a session backend really only requires that UserSession inherits from AbstractBaseSession and a SessionStore model.

It also wouldn't need an additional middleware (just a single session middleware).

from django-allauth.

Whatever solution is chosen, it must be able to work with different session backends. Many projects use cache based sessions. So, the approach taken by django-user-sessions does not match our requirements. Also see:

jazzband/django-user-sessions#52

As for QSessions mentioned in that ticket, that one offers at least both db and cache as backends, but I really do think our current solution is as simple as it gets. It does not require adjustments to your regular sessions setup (e.g. no need to remove django.contrib.sessions from INSTALLED_APPS, no need to alter SESSION_ENGINE).

from django-allauth.

Fair enough, perhaps it's just one of those unnecessary overrides that doesn't derive much in he way of specific value vs the approach here. This is definitely quite a bit simpler!

from django-allauth.