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.
Related
I am using smartphone authentication feature from firebase to register my users, but some of my users do not receive SMS codes in their mobile phones(signal problems...), and sometimes i really need these customers, so i create a test SMS code (using the real phone number, so they can receive SMS in the future). When they authenticate with the fake SMS Code, firebase create an ID with an UID and i can login again later with no problems, but happened that 3 times these users created with the fake number feature and with an valid and registered UID were deleted from the authentication list after some time, i cant find them anymore, and when i register them again, a new UID is generated, is this a real behavior of firebase, exclude test numbers UID generated after some time?
I've incorporated Firebase Cloud Messaging into my app. After messing around, I kind of understood the premise of how it operates. So, as a result, I structured my code so that when users sign up the FCM token is stored. After creating two accounts, I realise both FCM tokens for the user were the same.
Looked online and sorted this issue, and now I can refresh the token on launch, and still append the new FCM token when users initially sign up.
So now, I ask the question - Users are created with a fcmToken field (which I can refer to in my code), however, due to the fact a new token is generated on launch each time does this render the token(s) stored for each user useless? Or can I still push to the specific user using the fcmToken?
I've looked online, but can't seem to find an answer.
FCM tokens don't uniquely identify an individual end user. They identify a specific installation of an app on a specific device. When sending with that token, it doesn't matter who is signed in to the app (or if anyone is signed in at all) - the app will still receive it and need to figure out what to do with it. It's up to you to decide what to do with that message, given the sign-in state of the user. If you expect that your app could have multiple users sharing a single app on a single device, then you will probably want to send something in the payload to determine who that message was intended for, if necessary.
#doug great answer, but there's a common implementation problem when people share a device, so please add a warning, something like: often only the last logged in user should receive push notifications, otherwise he could see messages from the person who was logged in before. your backend should not only store all the devices a user is logged in, but also for each device who the last active user is and check this upon sending a push. the question whether you receive push or not when logged out is a common topic, too.
The way I understand Firebase Cloud Messaging at the moment, I will want to save all FCM tokens a user might have across devices to my backend and send a notification to all of these tokens at once when I want to notify that user about something.
Multiple tokens
Until this point, I assumed that each device only has one active token, however, reading this section of the documentation:
To enable this feature, make sure you have each sender's sender ID. When requesting registration, the client app fetches the token multiple times, each time with a different sender ID in audience field, using the token retrieval method for the given platform
Does this mean that I might need to target multiple active tokens per device?
Deletion
And now coming to the really important question. A simple solution to the above problem would be to simply store every token I ever retrieve in the backend and thus ensuring that my user will always receive the message.
However, what do I do if the user signs out of my app using Firebase Authentication, i.e. a different account is used in the same app on the same device?
I assume that the tokens I sent to my backend for this device will still be active - so now this user will receive notifications from another account because that account was signed in on the device previously.
I do have access to the current FCM token and I could delete that from my backend before signing out the old user, but considering the "Multiple tokens" section: how do I make sure that I can delete all FCM tokens of the old user from my backend?
Uniqueness
Additionally, assuming that old tokens are just dead for the device (will not trigger notifications anymore) when new ones are generated, can I be sure that this token will never be assigned to another device in the future?
TL;DR
How can I make sure that I have the correct FCM token(s) for my user stored in my backend and more importantly: how can I ensure that no tokens of other users are saved for some user in my backend?
I read through:
https://stackoverflow.com/a/40158260/6509751
However, I still do not know how to deal with multiple tokens.
Does this mean that I might need to target multiple active tokens per device?
An application has a single active token for each sender ID. It's fairly uncommon to have multiple sender ID, and you'd usually know if if you do. If you're sending from a single back-end, there's usually no need for having multiple sender IDs.
Is there a way to unverified a verified number in firebase account (phone authentication)?
There is more than two days I am trying to find a way to resend SMS code, in react-native-firebase but unfortunately I couldn't find a solution for that.
Now I think if I unverify a number or unauthenticate a number I maybe able send the SMS code again.
because as I tested firebase only send SMS code to unverified or unauthenticate number
As far as I know there is no way to set the phone number of a user account to unverified within the Firebase Authentication API. You may want to file a feature request for this.
Re-sending the verification code definitely isn't going to result in the account becoming unverified.
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.