Destroying all sessions for a given user?

[kleydon]

Hi,

I'm maintaining the express session store for Prisma (prisma-session-store).

Recently, a developer asked whether there might be a way to destroy all sessions for a given user (as might be desirable when logging out of all devices, changing a password, etc).

While this can be accomplished at the back-end application layer, it requires (I think?) downloading all sessions, and then filtering them, which might not be ideal if there are hundreds or thousands of sessions.

I'm considering adding the ability to destroy all sessions for a given user as a feature specific to the data store that I'm maintaining, but wanted to check in first, to see if something along these lines might be in the cards for the express-session library (and the session store interface it exposes) more generally...

Do you imagine this library would surface this sort of functionality in the future? Or does this seem like the sort of thing that ought to live in each specific session store implementation?

Any advice / recommendations / rationales would be much appreciated.

[revington]

@kleydon I implemented this in the past by changing the genid function. The idea is to generate a random id that we can find later i.e $userid-random(). Then in your database you can query by all keys starting with user id $userid-*.

The trick here is to overwrite the user session id once they log in.

[kleydon]

@revington - thanks for this!

[ultimate-tester]

The solution provided by revington is definitely a good one, it will do what you expect.
Though, I am not a fan of solutions that involve loops. Especially when you have a high-traffic site, you will notice problems. On top of that, having the list of sessions per user is probably not the complete functionality requested. Usually sites that offer the functionality you describe also show what kind of device the session is associated with, the login time, the IP, and other metadata.

Therefore, my suggestion is to leave the requested functionality out of session management but persist this information in the database. Upon login, the user session ID should be stored into the database together with all the metadata you want. You might think "But then you are storing data redundantly as my session ID is already in the database", but I disagree with that. You are merely storing a reference just as you would with other relations between tables.

[kleydon]

@ultimate-tester Thanks; appreciate your insight / experience on this.

[florianwalther-private]

@ultimate-tester I found this thread through a Google search. Can you confirm that I understand your suggested approach correctly:

1. When the user logs in, I store the session id in an array on the user object
2. When the user then changes their password (or does anything else that requires all previous sessions to be terminated), I get that array out of the user database entry and iterate over it, calling session.destroy(sid) for each of them?

So I assume it is safe to store express session ids in the database (sorry for the noob question)?

[ultimate-tester]

@ultimate-tester I found this thread through a Google search. Can you confirm that I understand your suggested approach correctly:

1. When the user logs in, I store the session id in an array on the user object

2. When the user then changes their password (or does anything else that requires all previous sessions to be terminated), I get that array out of the user database entry and iterate over it, calling session.destroy(sid) for each of them?

So I assume it is safe to store express session ids in the database (sorry for the noob question)?

Hi there, you're completely right in understanding. Session IDs are not a secret so they don't need special treatment, they get sent to the client after all (although signed, but that's to prevent people from "guessing" valid session IDs)

[florianwalther-private]

@ultimate-tester Thank you. Would you additionally check on each request if the sessionId is contained in the user array? I'm a bit afraid of having orphaned sessions because the destroy call failed but the session id array was emptied out.

[ultimate-tester]

@ultimate-tester Thank you. Would you additionally check on each request if the sessionId is contained in the user array? I'm a bit afraid of having orphaned sessions because the destroy call failed but the session id array was emptied out.

Good question. I currently have a quite naive approach by using user login and logout routes to store and remove the session ID from the database.

[revington]

@florianwalther-private @ultimate-tester there is no need to loop nor keep a list of ids.

The way I do this:

create a genid function that prefix id with user id

function genid(req){
  const userId = req?.session?.userId || 0;
  const randomId = /* random id without "-" char*/
  return `${userId}-${randomId}`;
}

supply this function to session when you create the session middleware.

When a user logs in just copy all session data into some variable and call regenerate this will terminate previous session and create a new one. copy old data back again to session.

How do you implement destroy all? just go to redis or any other backend and delete ${userid}-* sessions

[florianwalther-private]

@revington Thank you, that seems like a better idea and should avoid orphaned sessions (which I think can be very dangerous). I'll try that out 👍

[florianwalther-private]

@revington req is undefined when I try this. How did you set this up so the userId is available there?
I put the userId in the session object at login after the credentials were verified.