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.
Related
Is it possible, I can receive a verification code from an external app/website page using my twilio free number... as a trial account user.
I haven't tried the process either, I'm believing I could be able to verify a telegram account, having received the verification code using my twilio free number
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.
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.
Bit of context, I am trying to use Firebase for both authentication and data storage. Since my application deals with potentially sensitive data, the confidentiality features offered by Firebase (all Firebase communication is done via HTTPS according to their blog) seems like a great way to keep my data secured. In fact, the only problem I have with Firebase is that authentication last far longer than it should. As far as I can tell, it lasts through device resets, application rebuilds and loss of connection. Even worse, I have no idea how long it persists for. I've tried searching online but I can't find the information anywhere. As far as I can tell, it lasts around a day, but that's just a guess. I am using email and password as credentials for my sign in.
My question has two parts, does anyone know the default duration of Firebase authentication and does anyone know how to shorten it? Otherwise are there any other services that are similar to Firebase where you can set the authentication duration?
If I could shorten the duration to 4 hours Firebase would literally be perfect, other wise I might have to implement my own authentication, since authentication that last's for as long as Firebase is far too insecure.
Firebase Authentication (for 3.x or higher SDKs) uses two types of tokens:
A token that identifies the user. This token is created when the users signs in with the app and does not expire. To get rid of this token, sign out the user.
A token that allows the user to access the Firebase back-end. This token is based on the previous token, is valid for an hour, and is automatically created and refreshed by the Firebase SDKs.