Expire sessions form the same user

[jhihn]

It is possible for a user to login multiple times (from same browser or multiple machines). In any case, it would be desirable for some applications to limit this ability to just one session per user. (Auto-log off, security implications). The user may not already have a shared cookiejar either.

It would be desired to have some kind of support to specify how to match existing rows in the session store and delete them. For instance passport puts a 'passport: {/deserializeduser/}' object in the server side of the cookie. If I could provide some kind of match function, that would be awesome.

[dougwilson]

This module is the generic framework and has no concept of users or the like. This would really be something implemented in the store you are using.

[jhihn]

I can understand that perspective. But if I go to the session store layer/people, they are going to tell me that they are an opaque application data store and just they just store the data that they are given with their store-specific alterations. So I'm stuck at some layer that doesn't currently exist, AFAICT.

Additionally, having this above the store level would add to the abstraction from the storage library.

[dougwilson]

Gotcha. And just to throw in another wrench, having a session has nothing to do with things like authentication or authorization.

For instance if authorizing a user deauthorizes existing sessions, that is really an authorization concern. Even then, of course without methods from the store, we don't have a way to even scan the store (all they expose to us is read/upsert/delete only by session ID).

[dougwilson]

Basically, "to have some kind of support to specify how to match existing rows in the session store and delete them" would require buy in from all the stores all ready, as they would have to provide some way to do this kind of search for us.

[jhihn]

Well, I thought session level was the appropriate level instead of session-store because if I change from MySQL to Postgres or Redis, then I would expect the application to continue to work in the same way. Not implementing it in session level means there additional considerations aside from the backing store. This may be normal, I do not know myself if it is the 'norm'.

[dougwilson]

But I mean, you had the requirement

to have some kind of support to specify how to match existing rows in the session store and delete them

How could we do this without store support?

[gabeio]

This could be built into the application. When a user logs-in an entry into their list is made linking to the sessionId (probably another table or collection or etc.). Reversing that then you can look their user id up and delete the session (upon request of the user). On logout pop only that session from the list. Expiring sessions might get tricky though if you have one table set to expire there really is no way to tell the other table that value has expired separate from the rest (without a background worker).

[dougwilson]

Hi @jhihn it seems this discussion is starting to stall out without discussion for 7 days. Any additional thoughts or a response to my question?

[jhihn]

Well, it needs to be supported. There are legitimate reasons who you would want a user to only have one session. I'm surprised we've gotten this long without it.

The question becomes how do we do it in an application agnostic way? For that, I suggest that we be able to supply a function to the session store for matching and returning a list of session IDs which are then cleared from the session store, then the new session is assigned. For instance i would supply a function to check the user.id value for a match to the user id logging in.

It would be terrible if i had to peirce all those layers of absraction to add it to the app.

[dougwilson]

Well, @jhihn , that's what I'm saying: I don't see how that feature can work without the stores adding some method. Can you help us get a store to implement it so we can look at it? Perhaps outline what said function's API would look like and gauge interest in at least the top stores on our page to see if they are willing to implement it?

[jhihn]

I can do that but it will take some time I have a backlog at work...

I'm not so worried about the session stores implementing it as long as we can add it in in a backwards - compatible way. Then it can be added at anytime as the stores get requests for it. I'm using node-connect-pg-simple but that one isn't too popular. But I'll start with that.

[dougwilson]

Gotcha, that's fine :) please feel free to even make a PR here and we can then look and discuss the actual API of the feature you're looking for :)