[🐛] Auth iOS verifyPhoneNumberWithMultiFactorInfo invalid-phone-number error

[bthurlow]

RN: 0.72.7
RNFB: 18.7.3
iOS: 17.x

There appears to be an issue with the decoding of the MultifactorInfo on iOS when performing the MFA sign-in flow, this code is working on Android, but on iOS it appears that the phone number coming over is formatted as +*******1234 and in turn is throwing the invalid-phone-number error when calling the verifyPhoneNumberWithMultiFactorInfo method.

Tested on device and simulator with the same result.

The code below is based on the official documentation from here: https://rnfirebase.io/auth/multi-factor-auth

const mfaResolver = auth().getMultiFactorResolver(error);
            if (mfaResolver?.hints[0].factorId === auth.PhoneMultiFactorGenerator.FACTOR_ID) {
              const hint = mfaResolver.hints[0];
              const sessId = mfaResolver.session;
              auth()
                .verifyPhoneNumberWithMultiFactorInfo(hint, sessId)
                .then((vId) => {
                  setVerificationId(vId);
                  setMfaResolver(mfaResolver);
                  setShowVerificationForm(true);
                })
}

Ideas or assistance is appreciated.

[github-actions]

Hello 👋, to help manage issues we automatically close stale issues.

This issue has been automatically marked as stale because it has not had activity for quite some time.Has this issue been fixed, or does it still require attention?

This issue will be closed in 15 days if no further activity occurs.

Thank you for your contributions.

[bthurlow]

Still broken after upgrading to RNFirebase 18.8.0

[mikehardy]

Struggling with this currently on iOS in the firebase auth emulator (from firebase-tools package) but for different reasons

The phone number is in fact supposed to be for the hint display if needed, not for the verification. It is masked on purpose though that is a platform difference and leads you to believe the hint is used directly when that's not the case.

The hint also contains other information (most importantly a uid) and that is what firebase auth is supposed to use underneath in order to send the SMS code to the correct phone number.

That leads me to believe that on iOS for you to receive an invalid-phone-number error, something else is going on.

That said, our e2e testing for iOS MFA is currently disabled so that's a weak assertion on my part - it should work but I can't prove it at the moment.

The problem I see with the auth emulator is not an invalid phone number, it is that it will error with no MFA enrollment not found, and I'm unsure why. Next step is to try it against cloud auth vs emulator to see if it is an auth emulator issue or a general issue - investigation here https://github.com/invertase/react-native-firebase/commits/%40mikehardy/auth-mfa-ios-e2e-enable/

What's your test setup? Using the firebase auth emulator as the backend, or the real cloud auth services? If using real cloud auth services are you using a configured testing phone number with configured test code, or a real phone number?

[bthurlow]

@mikehardy We're using our staging environment, which utilizes the real cloud auth service with a test number and code. The same MFA credentials work on Android but fail with this error on iOS. I've attempted multiple times to trace the calls via Xcode, but have been unsuccessful at locating where the issue may be originating from. Based on the tracing I've done so far, it does get the Hint correctly but appears to die after that.

Let me know if there is anything I can do to help track this down.

Also, our app is currently using the following versions in our environment
RN 0.73.2
RNFirebase 18.8.0
iOS 17.2 Physical Device

[mikehardy]

Thanks for the extra info, really appreciated @bthurlow - your current test state is the likely future state for our e2e auth testing here because I think it's a requirement for TOTP testing anyway. It will should have the side effect of exposing for us the same thing you are seeing for phone testing as well.

Your dependencies look great - completely current - so that's not it.

Sorry for the hassle - I'll try to keep you updated here but in case this specific issue gets lost keep an eye on the changelog on any new releases

[bthurlow]

@mikehardy Thank you for looking into this. I will continue to troubleshoot on my side as well and will report any findings should I come across them.