Self Hosted single session per user
Is there a way natively with some built-in function or setting to enforce single session per user on local dev Supabase CLI or the self-hosted Supabase Docker? Or do I need to use logic to manually monitor sessions and handle this?
6 Replies
No native way comes to mind, i wondering if you could write a trigger on auth.sessions so that whenever a new session is created, you check the table for any sessions that exist for that user and invalidate the session with the earliest
created_atYeah that's exactly what I was thinking. I was looking at the go-true settings but I don't even think I want to get into that. I think what you suggest here is what I also agree with and probably the simplest and best way.
If anybody has any other ideas, I'll be watching this thread, thanks
no worries, best of luck
Just remember if you are triggering on non documented processes in auth to make sure you go check those at the first sign of sudden breakage. Supabase has changed several auth tables columns and functionality over time and there won't be any sort of change log if not something like the auth.users trigger they document to use.
I'm also wondering with Sessions and the default self-hosted configuration, am I understanding it correctly when I say that a user logs in and therefore a session is created, and the user then gets their session token and the refresh token. The refresh token is good indefinitely but one-time use so long as that session exists to be refreshed, and what can be controlled is the Session Token Expiration, but even if I have a 5-minute expiration, the session could be in existence indefinitely because I don't have the pro options of time box or inactivity timeout? In the case that I don't change anything from default, if I logged in and created a session, got my token, did some stuff and maybe refreshed it once or twice, then I closed the browser and went away for a month. If I come back, would the refresh token allow me to get a new session token for that same session from a month ago? Or is there some sort of default session timeout? I'm sure there is, because then the session table would grow infinitely if people weren't logging out specifically.
In the best-case scenario, I want to safely and reliably, as simply as possible, make it so that if you have a session and then log in somewhere else, the old session expires, and it's fine that that token is still floating around until it expires, but on refresh would fail. And the new session would work normally. On top of this, I would also like an inactivity timeout where if it hasn't been refreshed in some time, then automatically when you do attempt to refresh, you have to reauthenticate because the session would no longer work. Lastly, I would like a time box as well. Where even if you're not triggering the inactivity logic, and you are actively refreshing, I would like a maximum session length.
Or maybe even without these pro features, there are some defaults that I don't know about. I would like to understand that.
I'm perfectly comfortable implementing logic whether it's in Supabase itself with triggers or if it makes more sense to have a running process that is checking the Supabase sessions and applying this with code. It doesn't matter to me. My concern is that I would like to do it following the best possible practice for the sake of reliability and have the least chance that something from an update breaks this.
Your comment Gary makes me feel like maybe I should stay away from making triggers and maybe a service that is outside of Supabase would be better?
Thanks guys lmk what you think
grok but wrong i think:
Certainly the intent of the refresh token and JWT pair (which is what is called a session in the clients) works the way you say. That was always the case of you stay "logged in" until you signout from any device or a security event kills the refresh token.
Then Supabase added a session table in the past year or two. It is checked when making auth requests because if the session is gone, then the access will fail.
That is about all I know of it. Cookie/session type stuff is not involved. Database REST calls do not look at the session info and rely strictly on the JWT.
I don't know if they better define the session table or not.
Not sure if the Pro features are in selfhosted or not or how they manage them. Could be part of auth or a separate thing, just have never looked at that part of the source.