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.
Related
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.
Ok, so on a completely vanilla MVC5 template, I am finding that if I Login, tick Remember Me, close the browser and open it again, and then go back to the website I am showing as logged in.
Request.IsAuthenticated returns true, and I can access pages protected by the Authorize attribute, but my Session is empty.
My question is, is there any way to retain the users Session at this point also, as long as the application pool hasn't been recycled etc.
Thanks
Session state (which is what i assume you're referring to) is unrelated to authentication.
In my grails application using shiro, I'm using cookies to store the session data including authorization.
When a user tries to log in without accepting cookies, the login works, but then (as expected) the session is lost again and the user is logged out.
I don't want to change this behavior in general, I just want to display a notification to the user that his Browser needs to accept cookies.
So is there a way to tell that this user has been the one who TRIED to log in after the session data is lost, so that I can display a respective message?
I think running a test whether cookies are accepted on every page is a bit too much, therefore I'm heading towards the solution at login only.
You could use the grails session to store the current state of the user. Then, on login, check the grails session and determine whether to show your message or not.
I'm trying to figure out exactly when the event Profile_MigrateAnonymous fires.
My best guess from just tracing through my code is that it fires when it detects BOTH an anonymous membership cookie AND an authenticated membership cookie. Can anyone confirm this? I'm looking for real in depth answer here. Not just it gets called 'when a user logs in'.
Now - why do I care?
I was trying to keep the anonymous profile hanging around after a user had authenticated so that once they log out I'd still be able to tell who they were, and certain settings that may have been set.
The problem I'm seeing is that Profile_MigrateAnonymous is getting fired on EVERY request. Not just when a user has logged in. This makes me believe it to be a bad practice to keep the anonymous cookie hanging around - and that I should always call ClearAnonymousIdentifier();
For instance I have a new store and an old store. I want users that have access to the 'new store' to never be put back on the old store. Obviously - as with most shopping carts you don't need to autenticate to begin a session. Therefore I think the only way is to call 'ClearAnonymousIdentifier' as designed but keep a secondary cookie 'UseNewStore' to track which store they should go to.
is this a good interpretation. Or should I just not care that Profile_MigrateAnonymous is being called all the time?
Don't bother with it. There is a simpler way
Migrating Profile Properties During Log On
http://msdn.microsoft.com/en-us/library/taab950e.aspx