Enable multiple sessions per user

[waxlamp]

Currently, if you log into Multinet from different browsers, only one browser will retain an active login.

Instead, Multinet should behave more like Google accounts. To solve this, we need some way to map multiple session tokens to the same user. This will require a bit of database engineering--perhaps an indirection collection that maps tokens to user _id values.

[jjnesbitt]

To add, I think having a concept of Session objects is a good idea (here, Session just means our document structure for representing this data). This would mean that the cookie that the client now has directly maps to a Session document, which then maps to a user. This both allows for multiple sessions to be assigned to one user, as well as makes the logic for querying easier (i.e., find a Session document with a field exactly matching the user cookie, vs querying a list). It would also allow us to store extra information about each session, if we wanted to (I'm not sure what, but maybe site settings or something).

However, the down side to this, is that it adds another database query, which would slow down the retrieval of user info from a cookie. We'd have to see how much of an issue this is, and we may be able to do some optimization to limit the number of database calls. It's also important to consider that in the future, much of the information from the api may rely on the information about the user's login, as they may have access to privileged data. So increasing the time to fetch user information could propagate that to the rest of the api calls.

[waxlamp]

However, the down side to this, is that it adds another database query, which would slow down the retrieval of user info from a cookie. We'd have to see how much of an issue this is, and we may be able to do some optimization to limit the number of database calls. It's also important to consider that in the future, much of the information from the api may rely on the information about the user's login, as they may have access to privileged data. So increasing the time to fetch user information could propagate that to the rest of the api calls.

This is maybe a place where encrypting the user data and storing that in the cookie could be helpful. I would want to (1) make sure that is the simplest way to solve the problem and (2) rely on a third-party library to handle the encryption.

[waxlamp]

It could also simply be another place that Foxx microservices would be of use (the first one being the workspace indirection lookups).