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.
Related
I have used Google Sign In to authenticate users with Firebase Auth, and I successfully get back my Firebase User. I want to keep the user authenticated, when they come back to the app. How can I do the same?
Users already stay authenticated. After you restart the app, Firebase reads the credentials from disk, and refreshes the user's token. Since this requires a roundtrip to the server, it happens asynchronously. So be sure to await _auth.currentUser() to get notified of the user's status.
Whenever I'm wondering how to do such things, I look at the FlutterFire sample app. This specific line can be found here.
Yes you need to do the auth.currentUser() function in order to keep users authenticated and the best part is that this function will work even if the user is offline, which makes it very versatile.
I'm using firebase authentication for my app and I have the users sign up, login, and log out all set up and going. However, I'm a little confused on how to manage the state of the users login status. Currently, if a user is logged into the app, but doesn't use the app for an extended period of time, firebase doesn't recognize them as logged in. I'm looking at the documentation and the approach is a bit unclear.
Should I be storing a FIRAuthCredential every time the user logs in, and then call reauthenticateWithCredential using that credential?
Firebase Auth only requires recent sign-in for sensitive operations like: deleting a user, changing a user's email or password. These are for obvious reasons. You want to make sure it is the same user before making such sensitive changes. Otherwise, the user is considered signed in indefinitely by the Firebase Auth backend (your assumption that "firebase doesn't recognize them as logged in" is not correct). Of course, a developer may also require re-auth before other operations like updating credit card, shipping address, etc. A developer would check the auth_time on the Firebase ID token. Only in such cases would you re-auth. You should never store credentials such as password on the client to avoid prompting the user to reauthenticate. It is needed to protect the user's account.
yes I think that is going to be right approach or second approach you can try is like when a user press login button instead of directly calling Authenticate User put a check in which last login timestamp value will be stored when user login compare timestamp value and then perform selected operation as you want . NOTE - you will be required to check weather user exist or not , but I think first approach will be better as if you had noticed in many Social apps like kik it ask for reauthentication after a long period of time but first it authenticate user instead of displaying home screen it take to reAuthenticate screen
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.
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?
It isn't clear to me how the Google+ API platform deals with sessions. My web app uses the Google+ sign in button and after signing the person in I receive an authentication code that I can use for API calls. But the Google+ API docs don't indicate how to handle the sign in session from the server side. What they do mention is how to handle it in Javascript as outlined at:
https://developers.google.com/+/web/signin/session-state
They indicate to check the status.signed_in state which will be set to true if the user is signed in and then my client script is suppose to customize the UI accordingly. But that is nonsense for parts of the UI that require proof the user has signed in. A hacker could just as well put a breakpoint on the callback from Google's authentication, and change status.signed_in to true making the UI think the user is signed in. I need a way to verify on the server every time the page is reloaded to determine if the user is signed in. How am I suppose to do that?
how to handle it in Javascript as outlined at
The session state on the page you referenced refers to the state represented in the button.
From a server-side perspective, Google does not provide a state associated with users on a per-site basis.
A hacker could just as well put a breakpoint on the callback from Google's authentication, and change status.signed_in to true making the UI think the user
This would present the signed-in UI, but should not have access to actual user details.
The way that your site should probably be authorizing the user server-side is to validate an ID token or Access token that is securely passed from the client. All of the Google+ quickstarts show you how to do this and include instructions for getting started.