I'm using Firebase Authentication specifically the FirebaseUI library, Also users can sign in via Email, Google, Facebook, or Twitter.
Firebase Authentication does not support adding custom fields such as wallet balance, profile settings, etc. (This strikes me as being a very unfortunate thing to do), So I decided to create a table for users in MySQL and it contains default fields that are already Firebase supported and custom fields.
Now let's suppose the user trying to sign in, If the user signed in successfully, Then I will create a second connection with the server to check if the user does not exist and after that add the user to the table.
Sometimes the second connection will fail for some reason, In this situation, I want to sign-out directly and never let the user can continue to use the app as a logged-in user.
The Questions
Are there factors that can lead to failing sign-out? Yes?, Please
tell me what is the factors until I can handle that.
Can the user sign-out even if the network is not available?
What is the estimated time it may take to sign-out? Milliseconds or
Seconds?
Can the user sign-out even if the network is not available?
What is the estimated time it may take to sign-out? Milliseconds or Seconds?
When you sign the user out from Firebase, all it does is remove the tokens that it keeps for that user. This means that the signing out is both instantaneous, and can be done when there is no network connection.
Related
Note: I'm on the Blaze Plan
I have a firebase auth user that just set up a paid account, and they're receiving a RESET_PASSWORD_EXCEED_LIMIT yet my other paid accounts aren't. How do I reset this user's password? I'm not sure what the individual reset limit is, I couldn't find it in the docs.
I have 110 users which I've gained over 48 hours
Failed Solution: I re-created the account, but the new account, even though it was able to generate email password resets, it actually was a link that didn't work, leading me to believe it's a bug. The user had to create a new account with a new email.
From Firebase Support
An OOB link is the link generated for the reset password email, it
contains an oobcode which is a one-time code, used to identify and
verify a request. Saying this, each user is permitted to use a certain
amount of links, then if he exceeds the internal quota, the error
message “RESET_PASSWORD_EXCEED_LIMIT” will appear.
To reset the quota, you just need to click the link and reset the
password, this workaround is not good for a real user, but if you are
testing it can help you to reset the quota. The real workaround for a
real user would be to wait for a period of time until the OOB links
naturally expire.
To avoid hitting this quota, I recommend you to add a validation in
your UI of the number of retries that the user can request a
reset-email password email. For example, setting a restriction of four
requests maximum in ten minutes would avoid triggering our alerting
system. This is not the exact quota, but I am giving you a good limit
that you can set in your application.
How do I make it so that when a new user signs up in firebase, they can only login with that provider? Ex: a new user uses an email and password to sign up and then is rejected when trying to log in with Google.
I'm using Firebase with javascript in React if it helps.
What you're asking doesn't sound possible. The different auth providers don't know about each others' user bases. jackoboy on Google isn't at all related to jackoboy on Facebook. While they might have the same email address, that's never a guarantee that they are the same individual. So when jackoboy signs up with Google, there is nothing that can possibly stop jackoboy from also signing up with Facebook as a different account.
If you want to impose your own checks to see if the end user might be the same, you're going to have to write some code for that on a backend you control, then delete the second account if it appears to be the same person, by whatever logic you determine. Firebase Auth just isn't going to do that for you.
I am working on Firebase application ( Firebase version 4.1.3 )
My health care related application is made for dependent group of people such as children and seniors. However, most of my users are independent group of people age around 18-55. Most of my users use my application for their seniors/children. They need to create account for each of their family seniors/children member. Therefore, my users have to log in and out many times and they have to keep track of their family members' account. My first thought was I should make an account switching feature so that my user can switch their account back and forth between their family members to update information on my application.
After searches on Google, I found way to force switching account on Firebase authentication with Google provider, but those are not what I'm looking for.
My questions are:
Is it possible to store the multiple firebase auth objects (logged in object) in client side?
If it is possible, for how long will the token inside the firebase auth object last for?
If it doesn't last forever, is it possible to refresh update the token so that it can be use without authenticating with the social/phone login again?
The functionality you are asking for is not available out of the box. You have to build it on your own. I do think Firebase provides the pieces to allow you to build it (via Auth and Database).
Is it possible to store the multiple firebase auth objects (logged in object) in client side: You can have multiple Firebase app instances and each one have an auth instance with a current user. You would need to ask each user to authenticate though (you can't authenticate once and sign-in into all of the account). However, you can build your own user group login mechanism, where logging in with one "master" account can allow you to login with multiple accounts using custom Auth.
If it is possible, for how long will the token inside the firebase auth object last for. Firebase sessions are supposed to be indefinite. If a token expires (typically after one hour), it can be refreshed automatically if you are using real time database.
I do not think Firebase has that token capability. But what you could do is simply put the email address of the people in the device by Shared Preferences( for Android). When the user wants to log in with that user bring the email address just ask him to enter the password and then go through the log in process. If you do not want to use SharedPreferences you could simply store the users(also as you said family members) in Firebase Database and link them with the controller user so to speak. Whenever user wants the switch, go and bring the email addres of other family members from Firebase Database and ask in the client for the password and do the login by Firebase Authentication.Hope that helps!
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.
I have created an Appcelerator iPhone app based on Firebase authentication, which works very well. But now I come across some unexpected behaviour.
My setup is as follows: on app start, the user must login or register. During registration, the account is created, and the corresponding account data (uid, name, email, date etc.) is also stored in a /users/uid data entry.
When I remove a user from Firebase through the Dashboard, by removing it from both /users/uid and the "Login & Auth" tab, it looks all clear. But when the user opens the app, he still remains logged in.
How can I enforce removing a user, where he is also logged out the next time he opens the app?
According to the Firebase Google Group, this is a known bug with Firebase:
This is a known bug on our end. As you noted, after deleting a user,
existing auth tokens are still valid and can be used to read and write
to your Firebase database. Security Rules are still enforced on these
tokens and that user will still only be able to access their own
Firebase data (if your rules are set up as such). Those auth tokens
will be valid until they expire. There is currently no workaround for
this bug although we are going to be fixing this in a future release.
https://groups.google.com/d/msg/firebase-talk/Yr_wn02q0bk/eTM9hop3paoJ
The only thing I can think to do is check whether you can read to your users area, and if there's nothing there, force a log out.
From your behavior it seems like there maybe a configuration issue or just a bug. Does the users information get removed from corresponding data-source (DB or in-memory store)? I would start there then move on to researching how the corresponding cookies/tokens work and contact their support.
Though perhaps you shouldn't out right delete the user, perhaps just disable the user therefore, accomplishing the same result? Maybe this behavior will work properly.