While working on a game, we needed to enforce that each user has at most one active session in one installation.
Ideally if an user tried to login while they had another active session, we should stop the login process and prompt them to what they prefer: continue the login and possibly lose unsaved data from the old session, or abort the login and keep the old session active.
However, in order to view the user's sessions, we need to log them in first. This important for security reasons, and is totally fine since a priori we should be able to do something like this:
Log the user in.
In an "afterLogin" trigger, check to see if there are any old active sessions from different installations.
If there are, abort the login (logging them out) with a particular error code/message.
Upon receiving this error code, the app could prompt the user, asking which session they prefer keeping.
The user may abort the login, in which case we should do nothing, or they may decide to use this new session, in which case we could send a login request passing an extra parameter to indicate we're forcing a new session.
We log the user in again, and since we received this extra parameter, the "beforeLogin" trigger would know to revoke and delete any old sessions.
The problem is that, obviously, there are no "beforeLogin" and "afterLogin" triggers. There's also no way to pass extra parameters to the login request.
We can work around this by calling a cloud function that handles the sessions in the login success callback in the app... but then it's easy to think of scenarios where an user ends up fully logged in with two sessions from two different installations, and we end up having to deal with them.
We also thought of logging them in via a cloud function, but that too seemed to bring more problems rather than solving them.
Is there any better way to do this?
Related
I am having troubles to understand the login flow and signup flow in PassportJS and ExpressJS.What I really wanted to do is test if different sessions are being created. So I opened up a server and open two windows both at login pages. and then I log in and a session is created, but it is created for only person i.e. one who enters last, in my sessions table there is always one entry. Is this the expected behavior or is this wrong? How can I test this behavior in real time i.e. logging in 20 users and see 20 entries in my sessions table?
it depends on how you are handling sessions, most likely cookie, in which case you may need to refresh the browser, if that doesn't work. You're cookie expire date may not be set properly or you may not be deserializing properly. Read this for reference: https://scotch.io/tutorials/easy-node-authentication-setup-and-local
Passport by default allows the same user to login from multiple browsers and have unique sessions created. How can I configure it to destroy the first session when the user tries to create a second session?
Currently I'm using the 'Sessions' model to add the username to the record and upon subsequent login check by username if the sessions exists. But this increases traffic to the db. I'm thinking express must be doing it already or made to, keep the 'logged in users' information in memory so that the process can be simplified. I'd be thankful for ideas around how to achieve tweak with express for this purpose or any other workaround/suggestion.
Much thanks!
I saw that at least 4 users upvote this question, so I decided to create passport-strategy for that. The new strategy called passport-one-session-per-user. It's open source strategy you can access here: https://github.com/AminaG/passport-one-session-per-user
How to use it? add it right after session. For example:
app.use(passport.session())
var passportOneSessionPerUser=require('passport-one-session-per-user')
passport.use(new passportOneSessionPerUser())
app.use(passport.authenticate('passport-one-session-per-user'))
Not need for settings, or configuration.
How it is works?
The strategy, created an array that contain serializaed user objects, and sessionID.
Every time user logged in, the strategy check if the user already logged in. If so, it's flag the other session. The next time the user in the other session make a request, the strategy see the flag, and log the user out.
I'm thinking express must be doing it already or made to, keep the 'logged in users' information in memory so that the process can be simplified.
I believe the session model loggs the user in, and saves only that logged-in-ness in the session cookie. The server itself has no clue about who is logged in, but just checks this state in the (signed) session cookie provided by the browser.
You can write your own Passport.js strategy to handle it differently.
Let's say a user is banned in a website, but his session is still active. What's the best way of preventing him from performing an action that a banned user is not allowed to do?
The two plausible solutions I came up with are
making an additional checking previous to every "major" action,
like making a post in the forum, sending a private message, etc. to make sure
he is not banned (checking with the database)
destroying his session
Now, the latter solution could be done by setting an expiration for the cookie, but this would be bothersome for the rest of the users as they would have to log in again.
Other option would be setting a timeout in the session in which the scripts checks if he's banned with the database and then destroying his session if he is, but this seems like a bit too much.
What's the best way to deal with this?
If I understand what you mean by setting an expiration for the setting cookie, I would recommend against it. You want the control to be on the server side - don't trust your clients; they can easily prevent a cookie on their side from being destroyed.
Hopefully, whatever framework you're using has a way to delete the server-side data associated with a user's session, instead, invalidating the client's session id.
If your application is object oriented, you could do a check in your constructor, if the user is banned, and if he is, unset his session/call the log out function.
I am developing an application and I'd like to offer the user a possibility to stay signed in forever. If he checks a box, his session should never end, unless he manually logs out or deletes the cookie. If he doesn't, his session cookie will expire on closing the browser.
I considered three ways to realise this, but all of them contain pros and cons:
Saving a cookie with the user name and his hashed password:
Pro: The user can have multiple active sessions on different devices.
Con: If the cookie gets leaked by third parties, they can regenerate his session at any time unless he changes his password.
Generating a token which will be stored in the database and in the user's cookies. Then compare them:
Pro: As soon as the user logs out, the token will be randomized and all of his sessions will be destroyed. He will definitely be logged of.
Con: The user can only log in forever with one device. As soon as he logs in from another device, accepting to be logged in forever, his other token will be overwritten.
Only hypothetically: Save sessions forever on the server and give non-expiring cookies to the user.
Con: This is probably not realistic, because you can't store that much data in an efficient way.
I currently prefer the second way, because it does not seem to be as insecure as the first one and it's easily implementable. But I am still not convinced of it and I have seen that there are proven frameworks which do it another way.
Could you imagine another way which is maybe even better? What's your favorite and why?
Never save the password in a cookie. The second method is fine, and is how I think you'll find most apps implement this feature. Note that the session storage doesn't need to be a database. The cookie contains some unique (unguessable!) id, and this id points to some unique storage. It could be a text file in a directory somewhere, a database row, a JSON string in memcached, whatever.
Pro: As soon as the user logs out, the token will be randomized and
all of his sessions will be destroyed. He will definitely be logged
of.
Con: The user can only log in forever with one device. As soon as
he logs in from another device, accepting to be logged in forever,
his other token will be overwritten.
Don't store the token id as a column in the user table. Instead create a new cross table that allows more than one session per user. So, each device will have its own separate token, and thus, its own separate session which can be managed individually.
When a user logs out, you destroy only that one cookie and its associated session store. Any other sessions that the user has outstanding will remain untouched.
My web application requires a user to be logged in to view any webpage on it.
When a user logs in I store, in sessions, their username and password for retrieval later on. This all works fine but, if I rerun my project it seems to skip past authentication and go straight to the controller for that action.
What I presume is happening is that FormsAuthentication.SetAuthCookie(userName, createPersistentCookie); is remembering that the user is logged in but my sessions aren't updated.
How can I trap this scenario and update my sessions accordingly?
There are many ways of going about it.
First, you can choose, not to persist the cookie. But this will still cause the exception if the session has not expired and you recompile your project. Recompiling the project destroys the session state.
Though putting the password in session state is not the preferred way of going about it, I am sure you would have a valid reason of doing it that way.
However, if you want to do it that way, you can override the Application_AuthenticateRequest event in Global.asax. This event fires every time a request comes in and you can check if the request is authenticated (using HttpContext.Current.User.Identity.IsAuthenticated) and repopulate the session state.
By the way, can you elaborate why you need to store the user password in session state?
If I am correctly understood the issue,you can have base action class so and move the authentication mechanism there.So for every request this base will be invoked so you can make sure that the authentication mechanism is not skipped.