Consider this following scenario:
Suppose you are building an account-based application where you can access some parts of an application without having to log into an account. But, when the user wants to access that part of the application that needs to them to be logged in, we are directing to the LoginViewController and the user is now successfully logged in. There are multiple places where this is happening, and there is a single callback after the user is logged in: didUserLoginSuccessfully. Now, the problem here is, the user is expecting to resume whatever they were doing earlier, but to give them that experience, we don't have that information -- the methods and variables to perform the operations when the user is logged in -- saved.
I solved this using the concept of blocks. Saving all the methods that were to be performed if the user is logged in inside a block variable and executing it in the login callback using [block invoke].
Is this the right approach? Are there any better ways to do it?
Related
I am looking at the documentation for Firebase Auth in order to get my native iOS app's authentication to work properly. I am having some trouble logging out of my application (the signed in user is still present in the auth() instance) and I have come across this code as a possible solution to why I can't sign out, but I don't understand the purpose of fit.
What is a AuthStateDidChangeListenerHandle? Is it to help you pass the user among different view controllers or is it to sign the user out?
handle = Auth.auth().addStateDidChangeListener { (auth, user) in
// ...
}
Auth.auth().removeStateDidChangeListener(handle!)
When you attach a handler with Auth.auth().addStateDidChangeHandler your completion handler will get called whenever the user's authentication state changes.
The most common case of this is when the application starts. Authenticating the user requires that the Firebase SDK calls to the Firebase servers to validate the user's credentials. This may take some time, so instead of blocking your application code (which would lead to a bad user experience), your code is allowed to continue, and Firebase handles this client-to-server call in the background. Then when the call completes it calls your auth state handler with the update authentication state for the user.
You can always call Auth.auth().currentUser to get the current authentication state of the user. But if you do this at application startup, the call to the server likely hasn't completed yet, and you'll get nil back, since there isn't an authenticated user. This may be exactly what you want (for example: to display the authentication state), but sometimes you'll actually want to wait until the authentication has completed (for example: if you want to navigate to a different screen where you allow the user to enter their credentials). In the latter case you'll want to use Auth.auth().addStateDidChangeHandler to wait for the authentication to complete, to ensure you only navigate to the next screen once you're sure the state is up to date.
I've been looking around the web and trying to find out how to handle the user state of a logged in Firebase user where the following occurs:
User is already logged into the app.
Admin disable/delete the user from the Firebase Console.
User is still inside the app (although the account has been disabled/deleted on the Firebase Console).
After more than an hour, user is still inside the app. (Firebase ID token should have expired and addStateDidChangeListener() should've been called).
Currently, unless i call getIDTokenForcingRefresh() and signout() the user if the return error is due to disable/delete user. The user will still be logged in.
In summary, I've the following questions:
If a user is logged into the app, the user will remain logged in unless a signout() is called. It doesn't matter if the user account is disabled or deleted?
The Firebase ID token 1hour expiry only triggers the addStateDidChangeListener() but I'll have to handle what to do inside the handler?
What is the difference if I use reauthenticateWithCredential() to check for update state of the user?
Thanks for any clarification and help in advance! =)
I don't know if I will answer all of you questions but I can give you some info from my experience with Firebase.
As far as I know, if user gets deleted or disabled he will still be logged in app until token expires. Anytime you will try to manipulate with some data in Firebase (read, write, whatever) after the user has been disabled / deleted you will get an error in the result block. That is when you should check what kind of error it is and perform some actions. In this case, if error matched deleted / disabled user you should log him out and take to login screen. Here is a list of all errors.
reauthenticateWithCredential() is a way to do that but you will get the same error when reading other data from Firebase. So if a user is disabled, calling reauthenticateWithCredential() will return an error with code FIRAuthErrorCodeUserDisabled. That is how you detect that user was disabled.
I have an app which presents a login screen on first launch. When the user logs in, I give them an option to remain logged in. This establishes a session with an expiry on my server. What's the most appropriate way to do the following things:
Store whether the user is logged in or not.
Present the user with a login or logout option on application launch based on the validity
of their session.
End their current session if they choose to logout (or if their session is expired).
I'm guessing this is a common design pattern and there should be tried and tested ways to do this but I seem to be using the wrong terms to search because I haven't found a satisfactory answer.
Some ideas:
I would suggest you store your sensitive session information in the application's KeyChain. I wouldn't store here the state of wether the user is logged in or not, just store that in memory. Your webservice should be able to return an error when the session ceases to exist, or if the user has logged out.
If the backend determines the session's validity, then you should have a RESTful call where you can pass the session information, returning whether the session is still valid.
Again, if they choose to logout, then you could perform another call to your backend passing the session information.
For the Keychain, use the KeychainItemWrapper from Apple's examples.
I have a JSF login page using form authentication. I login users by calling HttpServletRequest.login(username, password). Logging out is done by first calling ExternalContext.invalidateSession() and then calling HttpServletRequest.logout() for the current user.
My plan is to keep track of the logged in user in an application scoped list by adding to the list anytime a user logs in and removing from the list when a user logs out.
I have two concerns with this approach:
If a user that was already logged in tries to log in again without first logging out, I want to invalidate the existing session and do some cleanup. How do I access the session for a given logged in user? I could also use this functionality to forcefully logout some users.
If a session expires (e.g. timeout) I want to remove the user from the list of logged in users. How do I listen for a session expiration?
Maintain a Map<User, HttpSession> logins in application scope yourself. During login, check if logins.put(user, session) doesn't return null and then invalidate it.
Let the User implement HttpSessionBindingListener and implement valueUnbound() accordingly so that it does a logins.remove(this). Or, if you don't have control over User, then implement HttpSessionListener#sessionDestroyed() instead to perform the remove.
Unrelated to the concrete problem, calling HttpServletRequest#logout() is unnecessary if you already invalidate the session. The user is tied to the session anyway.
Note: This is for a MVC 3 Intranet app. And yes, the two or more users MUST be able to be logged in at the same time.
I have an app that will require two or more people to be logged in to a form at the same computer at the same time. One person will logged in to do work, the other will be logged in to acknowledge/check some of that work.
Is Membership able to handle that? If yes, how?
They can't both be logged in to the same browser at the same time. Personally, I've never seen a web application where two users can be logged in at the same time in the same browser. I'd go with a more traditional workflow.
You'd have to have the first person log in, do the work, and log out. The work that the first user did would go into a queue for the second user. The second user would then log in, pick up the workflow from the queue, acknowledge/check the work, and then log out.