On my sign in page, I'm using my custom login and logout buttons. In order to show/hide these buttons according to user's sign in state, I need to be able to detect whether user is signed in. I can use the Gitkit's signInSuccess callback and store the user profile information and use that to detect the sign in state, but that approach would fail if the token has expired. I need a more robust approach to detect the sign in state.
The GitKit Sign In button is able to do it correctly. I'm wondering how it does it so that I can follow a similar approach. Can someone shed some light on how the Sign In button detects the sign in state?
You will have to do it on the backend. The status is stored in the gtoken cookie. We provide backend libraries to parse and verify the token. You can get all account info from there too.
Related
Im using Flutter and Firebase. I am trying to figure out if there is a 'built in' way to detect when a Firebase account has been disabled, so that the Flutter app can react and sign out that user if they are logged in already?
I could accomplish this task by adding a 'isDisabled' property to the users document since I already listen for changes to that doc and if it becomes 'true' then log them out. This would require that two changes are made, the 'isDisabled' is set on user doc and account is marked disabled under Authentication.
It just seemed like there might be a more direct way to accomplish this task.
There is not really a more direct way. Firebase Auth is not "realtime". When an account is disabled, the SDK does not know about it immediately. In fact, the user's auth token will stay valid for up to another hour after the time it was disabled. When the token finally expires, the SDK will no long be able to refresh it, and the user will become signed out. Your code will then see that the user is signed out, and they will not be able to sign in again.
How does FusionAuth work if you just completed the Change Password API, tried to re-login using the Login API with the oneTimePassword token, but you have two-factor enabled? Because, from my understanding, it sounds like I would need to interrupt the re-authentication flow for the user to get their two-factor code, after they just changed their password while already being logged in. Is this desired behavior? This line in the docs makes me think this is unintentional:
For this reason, this API will return a oneTimePassword that is intended to be used programatically after a Change Password request completes to keep the user logged in and provide a better user experience. A successful login will return you a new access token (JWT) and a refresh token. This will allow you to make the change password workflow seamless to the user.
I'm using both Google Sign in and Email and Password authentication in my react native application.
I set up a listener for the authstate and it all works fine, my users are authenticated, the application proceeds to the Main Screen and all.
However, when looking at the "authentication tab" on the Firebase Console, my users have both the last sign in and created at to be the same time, despite how many times users have logged in after that.
I noticed that if I log out and log back in, the "last logged in" tab, changes the value. That means that sign in with "signInAndRetrieveDataWithCredential" which gets called when my users log in, does change that value, but the auth state listener, which is then listening to the persistence of my users, doesn't update it. I think that would be very important, since the users are opening your app and "signing in", even though they don't go through a login flow.
What can I do to update the value and have an updated list of when users were created and last signed in? That seems like some important information to keep track of how your users are using your app and if they are coming back.
A listener just detects a change in state. It doesn't force a change in state. The last sign in time is the time that the user was previously fully logged out, then your app used a sign in API to sign in. It's not the last time that your listener detected a prior sign in.
When the user signs in, that sign in is effectively permanent. The sign in doesn't expire until the user explicitly signs out (when your code calls the sign out API), or the system rejects the automatic refresh of their sign in (the account is deleted or disabled).
If you want to know the last time your authentication state listener triggered, you can store that on your own, but I don't think it will necessarily give you very useful information. The best is that you will know roughly the last time they were actively using your app.
I used the token generated by my authentication server to sign my users in using signInWithCustomToken(token). Now what I cannot figure out is if they sign out, how will I sign them back in ?
I don't think saving the generated token in the database is a good idea because then I am going to have to give it public access so the user can access it.
Any ideas ?
If the user signs out. You have to go through the same mechanism you used initially to generate the custom token. Do not save the custom token. Besides it is only valid for a short period of time.
One example is if you are using our own username/password auth system. You ask the user for the username/password, verify it in your own server and then issue the custom token back to the client, client calls signInWithCustomToken and user is signed in. If the user signs out, you have to repeat the process.
On our app we are using "One account per email address". We want users to sign up using a specific authentication provider, which we keep track of, and stick with it.
What I've noticed today is that if I log in using a Google or Facebook provider I can then send myself a password reset link to the associated email address, which allows me to use the email/password provider instead.
There is a slight difference in behaviour depending on the first provider:
If I use Google first, after I use the password reset link I can now user either provider to log in, and both are linked to the same firebase uid. If I debug, I can see both in the providerDetails array on the authData object I get back from Firebase.
If I use Facebook first, after I use the password link the password provider replaces the Facebook one completely, although it retains the old firebase uid. At this point I can no longer use the Facebook login.
My questions are: is this behaviour intended, and, is there any way to switch it off?
This can cause confusion if say a user logs in using Facebook (which we track) and then later forgets and sends a password reset. It isn't the end of the world because they can carry on using the password login, but it certainly muddies the water.
Thanks
The behavior is intentional.
For end users, if they had signed into the app using Google or Facebook, and later they want to recover the password, the most likely reason is they (or an attacker) can not login with that identity provider.
After the user clicks the password reset link, Firebase removes the non-email identity providers to prevent other people from accessing the account silently. If the user still wants to add Facebook/Twitter login, they can do that via manual account linking (if the app supports).
In case the user's email service is the same as identity provider (e.g. #gmail.com users login into the app using Google), Firebase has an optimization to keep the identity provider since there is no security risk.