So I'm trying to nail down all of the potential ways Firebase Authentication 'verifications' could rack up quickly against the Firebase Pricing plan.
Please correct me if I'm wrong, but an auth verification counts against the pricing plan when:
User successfully signs in
User successfully creates an account
NOT when a sign in/creation fails for some reason
I can't find anything in the documentation about the firebase.auth().onAuthStateChanged() method counting against verification.
To check if the auth state has changed wouldn't you also have to check if the user is verified? If the refresh token has expired due to account deleted/disabled or email/password updated the account would have to be re-verified.
Is a 'verification' counted against the limit when .onAuthStateChanged() is ran at all?
A listener to onAuthStateChanged notifies you of changes in authentication state that happen in your app. Attaching a listener does not in itself cause any changes in the authentication state. It does not count against any pricing quota.
Note that token refreshes also don't count against any pricing quota. The only priced part of Firebase Authentication is SMS verifications, which only happens when you call signInWithPhoneNumber to sign the user in.
Related
I use Firebase Firestore and Firebase Authentication in my project.
I am testing out what would happen if I go into firebase console and manually click the "Disable account".
I would expect that if the account is suspended, the authenticated user (test#mail.com in this case) will immediately receive error whenever a Firestore database is called (eg. getDocs(q) or setDoc()). The reason behind this assumption is that I assume Firestore tries to authenticate each call before doing CRUD.
However, after testing out, here is the test and result
Login user (test#mail.com)
Do a db read or write ensure everything works which it does
Go to firebase console and disable the account (test#mail.com).
Try to do another db read or write. The result here is that I was able to still read and write which is not what I expected.
So here are my questions
Is this a normal behavior?
Can I write Firebase security rule to overcome this issue?
It would be less idea if I have to check if user is logged in everytime I do a firestore call. But if that is what I have to do, how can I do that. I believe getAuth()and onAuthStateChanged is not really suitable in this case. Reason being getAuth() seems to only check the database the first time it is called. Any subsequence call it only checks the app memory and do not perform any network request at all (Verified by looking into console network tab). Which is kinda weird. And onAuthStateChanged does not listen to firebase state change, it only listens to if my app logs a user in or out.
Abit of background on what I am trying to achieve
I want to be able to lock a user out from my app by changing something from the db. And ideally not having to PING every few second .
Update:
It seems like it takes about 1-2 hour for my app to automatically recognise that the account has been disabled. It took takes alot longer than what I anticipated. I would still like to know if there is a better solution rather than wait though.
Firebase Authentication works with a combination of long-lived refresh tokens and short-lived ID tokens. The latter tokens are valid for one hour from the moment they are minted, and cannot be made invalid after they are minted.
So it may take up to an hour before your client gets a new token, and detects that its account has been disabled. You can force the client to update its ID token at any time by calling getIDToken(true). This will ensure the client has an updated ID token, but it won't invalidate the older ID token (since it's impossible to invalidate a bearer token).
What you'll want to do is write the UID or ID token to your database when you disable the user account, and then check for that in your security rules.
Also see the Firebase documentation on detecting token revocation.
I know how to handle logIns and signUps and how to get current User but I was wondering if it costs a read if we get the user that is logged In or otherwise getting null if not logged in.
In otherwords does
firebase.auth().currentUser;
also takes up a read request.
Firebase Authentication APIs don't cost anything (other than phone authentication, which is covered in the pricing page).
When you say "read request", it sounds like you're talking about Firestore, which is a completely different product with different billing. Calling Firebase Auth APIs has no impact on Firestore billing. Firestore is billed based on your usage of its own APIs. Anything under firebase.auth() is not at all part of that.
When a page first loads on our React app / frontend, one of two cases is true:
Firebase auth found persisted creds and is trying to authenticate the user -- there will shortly be a callback on onAuthStateChanged
This isn't a registered user / no persisted creds found: Firebase auth is not trying to authenticate the user (they need to sign-in for the first time, or sign up), so there is not going to be a callback on onAuthStateChanged
We want to render different things in these two cases. To do this we need some way to know that Firebase Auth is actually attempting the sign-in.
How can we do this?
Simliar to Firebase Auth: How can I detect that firebase trying to auto signIn current user?
The only way of knowing if Auth is attempting to sign in is through your own knowledge of how the APIs are being invoked. There is no provided way to "spy" on the progress of the APIs. If you're not the one invoking the APIs (for example, using Firebase UI), then all you know is what an auth state observer tells you (fully signed in or signed out).
If you've just launched the app, and Firebase is trying to refresh the user token (from having previously been signed in), you don't really have a way of knowing how that's going. You have to wait for the first call to your observer to know if there is a user signed in or not. Your app should wait until that first callback in order to figure out how to proceed. The documentation doesn't really do a good job of explaining this.
Firebase allow free 10k authentications/month + 0.06 per each extra authentication. I am reading a documentation however it is still not clear to me what authentication/validation definition is.
Does that mean I can receive 10k free sms messsages per month and I will pay nothing extra when user already logged in and uses APIs to call firebase services OR it means I will need to pay extra even after user successfully logged in but in case of firebase internally wants to validate authentication status as kind of a background task is considered authentication too?
In other words: let's say each month I have 10k new logins (sms received) should I expect to be charged anything extra?
Firebase Auth only charges on successful verification.
So if a user tries to sign in with a phone number and an SMS code is sent but not used or received by the user, this attempt will not be counted. Only when user enters the code and successfully verifies it (successfully signing in), will that attempt count. The first 10k successful verifications are free. Any successful verification afterwards will be $0.01/verification for US/Canada/India and $0.06/verification for other countries.
I want to know if I need to re-authenticate with Firebase if I call firebase.database().goOffline and then call firebase.database().goOnline() at a later time. It is not clear in the documentation.
https://firebase.google.com/docs/reference/js/firebase.database.Database#goonline
The online status of Realtime Database is not related to the state of the user's authentication. Authentication state is handled automatically by Firebase Authentication. The token that identifies the user is automatically refreshed every hour by the SDK, and you don't have to write any code to manage that. It doesn't pay attention to whether or not the Realtime Database thinks it's online or not.