I'm using firebase for phone number verification via sms.
This works nice when the verification is automatically done (SMS is sent and automatically app reads it and does the operations related to that the phone number has been verified).
But I'm now trying to make the verification with the code that is sent in this sms, as maybe not every user is going to be able to automatically read the sms message.
I thougt that the function PhoneAuthProvider.getInstance().verifyPhoneNumber would be overloaded with some option that would allow to send that code and perform the verification, but unless I'm missing something there doesn't seem to be a way with it.
On the other hamd I know this way of performing a verification via sent code, but it does require to sign in firebase, and I don't want that unless there's no another way, all that should happen is that the user sends its phone number along with the code and if correct, firebase sends something that is understood by the app as that the verification has been correct (no signing in anywhere).
Is there a way to do what I'm mentioning?
I have a similar problem with my new app released in Google Play Store. I just don't receive de sms code.
I mention that when I tested the app in debug mode and release mode it worked perfectly fine. The problem occurs when I download the app from Play Store.
Maybe you are right and the problem is that i didn't login user, because at this moment rules in Firebase Database are read and write == true.
Related
I have a use case where I need each user to be identified by a phone number, this is because my shops will need to call the users who request an order , I have followed the documentation and all the github repo with the code
Actually the code worked, and sended to me the sms to verify and all worked just fine !
Now, before release, I have just plugged another phone, requested the code to verify and the code never arrived !
I just tried in another phone with another number and also the verification code has never reached that phone either.
But I actually verified a phone number with the actual code and it works, so, why is the code not reaching my users phone ?
My use case needs this feature and if this is on Firebase side I will need to move to another service
Any suggestions ?
For testing you can use the verification code you added with the test phone number on the console.
Firebase Console Dashboard -> Authentication -> SignIn Method -> Phone -> Phone numbers for testing.
Sometimes, firebase don't need to send the otp for confirmation. it can automatically be done.
This method is called in two situations:
Instant verification: in some cases the phone number can be instantly verified without needing to send or enter a verification code.
Auto-retrieval: on some devices, Google Play services can automatically detect the incoming verification SMS and perform verification without user action. (This capability might be unavailable with some carriers.)
In either case, the user's phone number has been verified successfully, and you can use the PhoneAuthCredential object that's passed to the callback to sign in the user.
https://firebase.google.com/docs/auth/android/phone-auth#onverificationcompletedphoneauthcredential
Check out the docs for Firebase Phone Verification for Android : https://firebase.google.com/docs/auth/android/phone-auth?authuser=1#test-with-whitelisted-phone-numbers
I've implemented firebase phone authentication in my app and it's working fine when the user uses the app on the phone which the user receives the OTP on. I'm able to verify the OTP perfectly once I receive the OTP on my phone.
But, I just thought of another use case where a user might be using the app on the tablet and when he/she has to verify their mobile number in order to continue using the app. So they enter their mobile number on the tablet and receive the OTP on their phone. In this case, when they enter the OTP they received on their phone in the tablet, I'm not able to verify the OTP since the onVerificationCompleted() method holding null in place of the value.
Can anyone help handle this case gracefully?
Thank you.
In that case, you have to use the onCodeSent and onCodeAutoRetrievalTimeOut callbacks and ask the use to enter the code and initialize a PhoneAuthCredential to complete sign in.
I am implementing push notification in my app after having it for IOS for a while.
Use case: I have user login, and accounts stored on our servers. I only want to send push notifications when a user is logged in, and only for the user currently logged in. Notifications are targeted to the individual user.
To do this, i fetch the token using
FirebaseInstanceId.getInstance().getToken()
, send push token to our server when user logs in, and remove it on logout.
Everything works as far as registering token, sending the token etc., HOWEVER, there could be scenarios where this doesn't work, for example if a user logs out with flight mode, so our server still has the token and thinks it should still send them.
On IOS, there are two local functions, register/unregisterforremotenotifications, that basically turns notifications on/off, regardless of whether my server could be contacted. I can call these on login/logout, and IOS won't show any remote notifications for my app, and i'm safe.
However, with Firebase, i can send the token to the server on login -
for logout, however, its more complex since there's no "local" system-function to call that i can find.
The best thing i've figured out, is to always send a 'Data' notification,
as described in this question,
so that my notification service always gets called, even in the background, and there check if i am logged in, and not show the notification if i'm not.
However, the notification for the wrong user will still be sent to the phone, and it's a risk, for example if i, god forbid would have a bug... or the notification gets logged somewhere in the system.
Sooo, my question is if there's any way to disable notifications on logout via Firebase?
I hope this makes sense, thoughts much appreciated!
Yes, what you do is you create your own Login and Logout APIs.
In your Login you should be storing your Token for PUSH notifications.
then whatever data triggers need to PUSH do a loop and build a push for known registered tokens.
On logout, simply delete that token from your Database and the loop will no longer include it for PUSH. You are correct using DATA tag will only work in foreground, but could be for wrong user that is correct.
If you do not have a backend, then please provide more clarity as to where/how you are storing and using your tokens to PUSH so I can help you further.
I have done this exact scenario to avoid wrong person getting push, but I support foreground and background on my scenario, so only logout or expired token will disable the PUSH on my app.
There are two ways:-
Your app supports multi user login at the same time scenarios :-
You can probably store the device token in share preferences with a boolean flag , when user relaunch the app , check if the flag for deletion is set then you can try deregistering from the service on server.
If it fails then again you can do the same , so it would be something like checking boolean flag for account deletion on every app launch to make sure it deregister.
Your app supports single usr:-
You can simply delete firebase instance Id before signing into the account. This would take care of the scenario where a different user had signed out offline and you were not able to de register from your service.
You can also handle scenarios when to show notification based on accountId or user Id of the signed in user.
I am using parse as my app back-end service provider. My app has really important feature of Push notification.
Parse is not saving the device token in some cases. Mostly when user is installing the app from America/Los_Angeles region.
Is this Parse.com sdk integration problem or Google is not sending device token in some region? How can i fix this issue?
I've just ran a quick check on our Parse backend and found that there are also missing device tokens in our database, too.
I think you should not send push notifications based on device token, but based on user on that device.
To do that, first add a new field in Installations table called user. If your app requires explicit login from user, then when user logs in, update the installation with that user's ID. If it is implicit (registers upon installation so App is ready to go as soon as user opens the app), then just associate that user in the same manner on app install.
In the end, you are most likely to want to send your notifications to your user rather than a specific device. This also makes data transferring a lot easier.
This issue was sometimes observed due to failure to get the token from Google. You should check the device token availability, if you don't get it, you should try it again after some time from your app.
I have an app that runs across iOS and Android. I'm working to add push notifications to that app.
At a very high level, devices register with the Apple Push Notification Service (APNS) or Google Cloud Messaging (GCM) and receive a token. They then hand that token back to the server that's in charge of sending notifications. That server, when it wants to, sends a notification to APNS or GCM and says "send this notification to the devices with these tokens".
So, my apps need to be able to securely send their tokens to my server, and delete those tokens from the server when the user no longer wants to receive notifications. It's very easy to add a simple CRUD page on the server side which handles ?create=<token>, ?delete=<token>, etc.
But what happens when someone goes to my server and starts spamming random values for ?delete=<token> — it seems like they'd be able to just delete random device tokens at will?
I've thought about the "delete" case a bit more, and I think it should be easy: the app can just send along a generated public decryption key with the initial “create this token” request. That key can be stored against the token. When the app wants to delete, it can send along the encrypted copy of the token, and the server can match the token against the decrypted copy, verifying that the app must possess the stored public keys matching private encryption key (which is a secret known only to the app).
What happens when someone starts spamming random values for ?create=<token> — do they get to just fill up my database table with fake device tokens?
I can't see an easy answer — rate limiting "create" requests from any single IP address seems to be about the best we can do without registration involved. That obviously isn't going to help us against any distributed attack.
Ideally I'd like to enable push notifications by default / without the user having to "register" or anything like that. My first thought is that each device token should be tied to a known canonical Apple ID or Google account — but how do I stop users from falsifying those? Do devices come with a certificate that I can get an authoritative public key for (in which case each device can just get a row tied to its public key)? What's the best way for me to implement authentication here?
The solution to the problem for android can be found Here. In brief it can be summarised as
You use the GoogleAuthUtil class, available through Google Play
services, to retrieve a string called an “ID Token”. You send the
token to your back end and your back end can use it to quickly and
cheaply verify which app sent it and who was using the app.
A lot of good questions here. :)
Let me try to break it down.
General thoughts
I don't think it's good idea to mix Android and iOS here. High level push notification architecture is similar between them, but that's about it.
Tokens are long (as I remember iOS token is uuid). So, there is no way to guess it by just randomly trying different values. So, I would say ?delete=<token> case is non existent.
The case of ?create=<token> is more realistic. First of all, somebody can bring your server to knees, registering millions of tokens. Also, if you are sending some sensitive information via push notification, you may don't want it to be received by non authorized app users.
Android solution
For Android it's easier.
As soon as you get a token on the server, just send a push message with some randomly generated string (store it in DB). Your application on a device will get this string and will send it with the token to the server (via second web call). And your server make sure that it will send anything to this token only after it was authenticated.
This way you rely on GCM ability to deliver messages to correct clients to make sure that authentication information (random string) is delivered to your application.
iOS solution
The problem with iOS is that push notification doesn't automatically trigger code execution, if the application is suspended or in background.
So, if you will try to do the same thing and a user accidentally exits your app, while push notification is being deliver than your app will never see it.
You can do following (the idea is basically the same as for Android, only with difference that we may need to require user interaction)
Push notification with a message "Please run my app and enter X" (where X is some random string)
This way, if your app is in background, a user will click on this message, enter X and your app will authenticated to the server.
In the case, if app is in foreground, it will get push payload and can authenticate directly.