I need to fetch some extra information after current user have been logged in.
I'm a bit lost in the "automatic" login flow, once user have already been logged in and app restart, loading user session from disk and refreshing.
I would like to get notified (one way or another) when it happen.
Any idea? track?
This is one of the main problems I encountered when using automatic user log in, and I have not figured out a solution yet. I asked about it here on the parse gh repo. I could not use the init method of the subclass, because I had to modify the object on automatic user creation (which the library asserts on), but in your case, you could use this technique to be notified of the user creation. (create user subclass, register it, and override init method)
Related
I'm using the Unity API. I let a user delete their own account. It's accomplished via ParseUser.CurrentUser.DeleteAsync()
I then call ParseUser.CurrentUser.LogoutAsync(); to delete the local ParseUser object on their device.
This works, but afterwards, the now-deleted user's session is still up, buty the associated user field is now a broken link.
How can I end this session? I tried to get a reference to the session before deleting the user via ParseSession session = ParseSession.GetCurrentSessionAsyn(), deleting the user, and then the session, but the session.DeleteAsync() fails.
Edit (clarification):
I check all Tasks that return from my various function calls. I detect when things fail, and that's how I know my ParseSessions aren't being deleted (plus, they're showing up in Parse's CORE session list).
I just can't find a way to make sure the session is ended from the client's side.
DeleteAsync returns a Task Object. Try using that object to ensure that the deletion has completed prior to calling LogoutAsync()
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?
IBM Knowledge Center states that
Server disables security access checks during subscription execution
but does not mention the user credentials the code uses to execute which you need to know in order to map user RunAs roles on the application server.
What user credentials does FileNet use to execute event action code?
As I understand, when you create async subscription it will be executed under p8boostrap user.
And it will keep user context when you execute syncronious subscription.
But you can check it for sure.
It is using the user who triggered the action. E.g. if a user changes a property of a document (let's say DocumentTitle because it is always there) and clicks save, then an update event will be triggered which launches the subscription (if subscribed to the update event) which launches the action. Use synchronous for short running tasks, you can immediately show the update to the user. With asynchronous the user will have to click "Refresh".
Security can be a pain if not planned carefully at the beginning, for the action to be executed, the user has to have rights for the subscription, action event, document class etc. basically for everything involved or the user will get a cryptic error message when trying to modify the DocumentTitle.
Source: personal experience, sorry no official reference, if in doubt verify first.
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'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