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
Related
I have a laravel webapp and I check if the user can perform certain actions or access certain information at every step of the way not just during the login. For example when they wish to view their assets I check for their UAC, after they click on them I check again, even if the edit, delete buttons are not visible, there is still a check in place in the code. And this pattern continues throughout the whole webapp. Is this overkill, will it make my webapp too cluttered with checks all over the place?
Yes, it is. Every time you don't check for access before performing a privileged action, you take the risk that an intruder might find a way to bypass your earlier checks and somehow trigger that action without actually having proper access to it. A few extra checks are a small price to pay for robustness and peace of mind.
In particular, you should always re-check privileges on the server for each new request made by the client, since you should never trust user input, and since everything the client sends to the server is potentially under the user's control. For example, even if you disable the "edit" or "delete" buttons in the client interface, what's to stop a malicious (or even just inquisitive) user from re-enabling them e.g. through their browser's developer tools, or even from simply spoofing the actual edit/delete request that the button would trigger?
If you're lucky, all a missing server-side privileges check will do is let some user see a bunch of deleted garbage. If you're not so lucky, it might give them full admin access on your site.
It is indeed a good practice and middleware can help you achieve this goal more easily.
Check the Laravel documentation for more information
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.
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.
I have implemented custom membership provider in my project. i kept one flag on database to get the users online. i want to reset this flag on the log out, i can do this if the user log out properly . I have to reset the flag on database even if the the browser closed directly or on any machine failure or normal time out, any tricks on membership provider to solve this. experts am waiting for your answers!!!!!!!
Thanks.
just put a field for users like IS_LOGOUT_BUTTON_PRESSED typeof(bool) default false
if the user click LogOut set it TRUE.
if the user closes browser, it will stay false. Then you can see what user did.
I am afraid that you are tilting against windmills.
You will notice that the sql providers implement the 'users online' by simply updating last activity in most all provider methods (and subsequently the stored procedures) and then using a predefined 'online time window' to determine if the user may still be online.
To implement an authoritative 'is_online' flag would require that you have complete control over the user's means of starting a session and ending a session, which you do not and can not do due to both the nature of the browser ui and the way that sessions and ticket expirations are bumped.
So you can never really be sure whether a user is online or not, rendering any efforts you have made to track this metric unreliable.
And unreliable data is often of less value than no data at all.
I am quite certain that you will find nothing but frustration in attempting to apply an absolute, as described in your question, to the stateless and freeform nature of sessions and tickets.
Sorry I have not better news.