Replies: 2 comments 8 replies
-
It's not not possible, it's just that Litestar does not have the concept of a user account. It can store session data for you and handle authentication, but you'll have to provide the user management logic yourself. The easiest way to go about this would be to simply go into the session store, fetch all the user sessions and check if they need to be invalidated and then delete them from the store. I would recommend against duplicating the session logic in your database, since storing this data in 2 places leads to synchronisation issues you'll then have to take care of, e.g. what is the source of truth in case there's a conflict? An alternative would be to implement a store yourself that acts as your session store but is backed by the database. Functionally, this would make querying easier, but to be honest, unless you're expecting to deal with a massive amount of users (think north of a few hundred thousand), there will be no problem just checking the sessions individually if you're using Redis and especially not the |
Beta Was this translation helpful? Give feedback.
-
Might be a "stupid" question but I feel like seeing ghosts because something stopped working that worked the whole time the last days: On login, when there is no user session yet, calling |
Beta Was this translation helpful? Give feedback.
-
Hi, I'm trying to figure out if it's possible to administrate server side sessions, e.g. to invalidate all sessions of a user account that has been deactivated or add session data of that user without a user request.
From this question I take it that this is not possible (or only partially -> delete 1 or all sessions), but since this is a few months old I wondered if that has changed since then.
My best take on this is as follows:
session_store
and thesession_backend
available globally as an app dependencysession_store
session_backend
for serialization and deserialization)Using the combination of
session_store
andsession_backend
seems a bit awkward to me, so this made me skeptical if this is the right approach. But maybe it's just like that because editing "global session" data is not the preferred use case since for most situationsrequest.session.get
andrequest.session.set
would be sufficient (getting/setting user session data based on a user request).Another thing: I think it would be useful if
request.session.set
would return the session id (instead of having to fetch it from the cookies afterwards).(This snippet misses the data models but should not matter for the question)
App setup (this misses the database setup and the user model but should cover the relevant aspects for this question):
Beta Was this translation helpful? Give feedback.
All reactions