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
Related
I have auth working fine. Users can log in and out, no problem. The thing is, if users share a login, they can all be logged in at the same time as the one user. Not good.
I need to have CakePHP know when a user is logged in, which I assume is a process started using:
'Session' => [
'defaults' => 'database'
]
As per the Sessions book page.
It's then I get lost. Unless I have missed it there is no reference to limiting users to one active session each. Has anyone come across this before and, if so, how did you work around it?
To clarity:
All sessions deleted from DB & all cookies deleted in browser = nothing set in either when visiting the /users/login page (incidentally, this has been set up as per the tutorials - nothing fancy).
Login = session set in db with id corresponding to cookie in browser. Exactly what you'd expect.
Logout (which then redirects back to login) = old session removed then replaced by another in DB and cookie. Different id. So something is picking up the expired cookie and refreshing it. Hmm.
The information held in the cookie is just the session id. In the DB it's simply:
Session id | a blob | expiry time
I assume you save users and sessions in a database (by default in cakePHP it is named sessions).
Add an active_session field, update it upon login, check it on requests to ensure that current user session id matches the last one stored in the database.
On Login action do:
UPDATE `users` SET `active_session`='$session_id';
When user goes to a page that requires login, you search that value:
SELECT * FROM `users` WHERE `active_session` = '$session_id';
If the user signs in other place, the previous session key gets overwriten, and the SELECT above returns an empty result-set.
It's possible to clean the old session token before the update, so this way old session will be destroyed on per user basis.
Be careful, if you are using AuthComponent, it might rotate sessions itself, for more information you may find in the corresponding section of CakePHP manual.
I'd definitely go AuthComponent-way, and wouldn't re-invent the wheel in CakePHP.
I tie users to their cell phone. Every day they get a new 6 digit code via twilio sms. Makes it hard to share logins, but not impossible. Ultimately, I would like to track how many different machines a users uses per day and establish some fair use limitations. If a user uses three or four machines in a day, that's fine, but when they start using the same user id on twenty or fifty machines a day, that might be a problem.
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?
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.
I was wondering if it ever would make sense to have two concurrent sessions in the same browser? There could be two types of cases with this:
1) A user opens a browser window and logs in as user A, starting session 1. Then he opens another browser window (in the same browser) where he logs in as user A, but starts a different session, session 2.
I know that this is often not possible in many browsers, as one session cookie is set for the entire browser. However, in some browsers, it is possible to have multiple sessions in that manner.
2) This is similar to 1, except that the second time the user logs in, he logs in as user B, starting session 2. So now you have a person logged in as two users in the same browser.
Finally, allowing these things doesn't seem like the best security practice and neither does it seem to be practical. What do others think?
First thing First as the your Assumption is wrong. First of all you have to understand that when Single website is accessed from browser have single session and its not possible to simultaneously run different session of same web Browser.
It seems you have wrongly understand the working of Private Browser. Private Session are not made not to share information cookies and data with other public session and vise versa also. As soon as you close the Private Session all the Cache, Cookie and other things are deleted for forever.
I have not seen any web browser supporting the Multiple session of browser.
But an alternative approach is available i.e you have to create different Web Browser Profiles which can help you as each Profile data is maintained separately and have no conflict with other sessions.
One possible scenario currently I am facing requires allowing multiple user sessions from the same browser and I have not been able to find a proper solution for it yet.
We are using Yii framework. Currently we have two kinds of users i.e customers and admins. Both login from the same login form and use same session name and variables to store session information. Only based on type column in user table(customer or admin), the user is taken to appropriate views. In one of admin views(pages), there is an option for admin to log in as any of the users and propagate through the user's view in an iframe. The problem is that when the admin open two tabs and logs in as two different users, the session information of one overwrites the other and we start getting session related issues.
Can anyone suggest me a proper way to handle these kind of issues. I have searched a lot on trying to handle this with multiple sessions, but have not been able to find a proper solution yet.
There's nothing to "provide support for" here. One browser cannot hold more than one session, since it only holds one unique cookie per site, regardless of window. If a browser actually has a mode in which it supports holding two separate identical cookies per site, then it's the same as if the user logged on from another browser or another machine. That certainly should work; i.e. you should not try to subvert that behavior. A double session inside the same browser is then just a specific instance of this multi-session behavior, nothing special.
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.