Open efstathiosntonas opened 1 week ago
The latest updates on your projects. Learn more about Vercel for Git ↗︎
Name | Status | Preview | Comments | Updated (UTC) |
---|---|---|---|---|
react-native-firebase | ✅ Ready (Inspect) | Visit Preview | 💬 Add feedback | Nov 19, 2024 10:24am |
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
@mikehardy I have signed the CLA in the past 😢
Right now it's hardcoded, I have created a patch that sets the xxL
and 60
to 0L/0
. I have tested the timeout (set to 0) but still I had the issue back in the days.
It's a 2 year old patch, probably this is fixed upstream but I do not dare to remove it haha, it serves me well and got 0 complaints to the day.
I do not do anything fancy on my end with Phone auth, guess it's classic Android stuff braking things around on the 30K devices out there. It was not a major issue, I had about 10-15 users complaining out of 25K back then.
ihmo it's nice to have this option even though it's anorthodox and doesn't align with Firebase SDKs. Thing is, changing these values is not even documented (last time I checked was 2 years ago).
We can extend this PR to reach modular apis too. Don't know about timeouts
, before messing with xxL
and 60
I've played with it but didn't work as expected.
Conclusion: If you think we should ditch this PR, let's ditch it. Maybe a poor soul will reach here from google land and apply the patch directly on ReactNativeFirebaseAuthModule.java
🤷♂️
ps. don't forget that we have bumped react-native like 30 times since then, maybe there was something that was messing with the listeners/activity
I was looking through this stuff and found a different issue you commented on:
https://github.com/firebase/quickstart-android/issues/296#issuecomment-1736910311
Looks like there is the "instant verify" case, where Play Services does some magic related to your google account on device. And there is the "SMS auto-retrieval" case, where Play Services / firebase gets the OTP before the user sees it and auto-logs in.
In your comment, you indicate that this patch (or the hard-coded version you've been using where just set it to 0L/0) disables the feature, but it was on the "instant verify" issue upstream.
Does that hard-coded patch actually stop both forms of auto-verification? If so that's unexpected, but interesting and this becomes much more interesting in my opinion
I was looking for another way to disable it by using tools:remove in AndroidManifest to disable the SMS Retriever API permission / intent but I couldn't find that so I think Firebase must be doing it some other way.
I was originally against this as an idea because I think it's all working now, but after reading the instant-verification can't-disable-it thread I think it's bigger than just auto-SMS-verify, and this might be useful - but only if your patch actually disables both in my opinion
It blocks everything, if the user doesn’t enter the code manually it’s not digested by firebase auth at all.
Capacitor is passing it as an option:
flutterfire pass it as an option too:
soooo, pass it as an option or as an on/off switch?
At some point in time I believed that firebase was automagically trying to verify the phone number even if the OTP haven’t arrived yet because of the google account on the device had the (verified) phone number I was using to sign in 🤦♂️🤦♂️
Very interesting - all of that. Hmm. Very useful feature if it is the only way to completely disable both auto-verify capabilities. You can't reasonably test phone OTP behavior otherwise as google will likely auto-vierfiy.
We have it as an optional boolean already on one method - how do you feel about following this pattern to do all of them, vs maintaining new state via settings?
Not sure how to squeeze that into the modular API but anything that did so reasonably seems like it would work
Introducing
autoOTPVerify
setting for Android devices, when this is set tofalse
the OTP handling must be taken care from the devs instead of letting Android automagically digest the code.This can come in handy in some scenarios where firebase auth throws
The SMS code has expired
when using phone number in certain Android devices.usage, put this at the very top eg.
index.js
orApp.tsx
after firebase is initialized.manual OTP handling:
@mikehardy hi, I've been using this for like 2 years with no issues. Let me know if everything looks good (don't think I've missed something) ~and I'll update the docs too~. Can we create e2e test case for this? 🤔
Release Summary
Checklist
Android
iOS
e2e
tests added or updated inpackages/\*\*/e2e
jest
tests added or updated inpackages/\*\*/__tests__
Test Plan
Think
react-native-firebase
is great? Please consider supporting the project with any of the below:React Native Firebase
andInvertase
on Twitter