OTP is coming as web login and not detected by the SDK

[hkchakladar]

Step 1: Are you in the right place?

Yes

Step 2: Describe your environment

• Android device: Samsung M21
• Android OS version: 10
• Google Play Services version: 20.47.14
• Firebase/Play Services SDK version: _____
• FirebaseUI version: 7.1.1 (Latest)

Step 3: Describe the problem:

Problems are regarding sign-in and while upgrading from 6.x to 7.x :

1. SMS OTP is not detected automattically.
See attached video, OTP is not detected in the latest version.

firebase-ui-auth.mp4

2. Showing internal Google project ID/Default firebase hosting site in a custom tab while signing in.
As seen in the above video, while signing in, a blank custom tab is opened with my Default hosting site i.e. < google-project-id >.firebaseapp.in which has internal Google project ID (Instead of my desired site name). Why is this page coming?

3. OTP is showing as web login to Default firebase hosting site
See thess OTP messages, now the OTP is coming as if signing in to web (That too from Default hosting site with internal Google project ID (Instead of my desired site name). Compare with old OTP.

Expected Results:

1. OTPs to be detected automatically as earlier.
2. No extra custom tabs (if it's required, then show my selected website from the Firebase hosting sites)
3. OTP messages should show my app name, instead of website. (if it's required, then show my selected website from the Firebase hosting sites)

[samtstern]

@hkchakladar thank you for the super clear bug with video! I actually think this is a Firebase Android SDK core issue and not an issue specific to FirebaseUI so I am going to transfer it there.

[google-oss-bot]

I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.

[samtstern]

@malcolmdeck can you take a look at this one? Transferred from FirebaseUI

[efstathiosntonas]

I'm having the same issue, the code is not recognised by the app and later on when user tries to enter it manually it returns "sms code expired". Nothing changed on code, just updated SDK.

[xJon]

Having the same issues as described here, after updating to the latest firebase_auth. Any upcoming fix?

[malcolmdeck]

I can provide some clarity here. Versions of the firebase-auth SDK that are 20.0.0 or newer provide 2 means of application verification: SafetyNet and reCAPTCHA.

If phone auth app verification happens via SafetyNet, the text message uses the App name, since SafetyNet can attest primitives about the application that we can use to determine the application name successfully.

If phone auth app verification happens via reCAPTCHA, the text message uses the domain name that the reCAPTCHA verified. As presently implemented, this does not translate into an Android application name, since the primitives attested are different. We're considering ways to improve this behavior, either by translating into an application name or by using a developer-specified domain.

SMS auto retrieval is implemented via the SMS Retriever API. This requires appending 12 characters to the text message. In some cases, this will bump the message past the character limit for a single text message. In that case, we do not attach the necessary characters to trigger auto-retrieval. This shouldn't invalidate anything about the code - it still has the same lifetime that it had before, it just may not auto-retrieve.

Hopefully that clears some things up. If you have specific bug reports (such as reliably being able to trigger "SMS code expired"),feature requests (such as needing to be able to specify the domain or have reCAPTCHA still use APP_NAME), or other questions that aren't covered by this explanation, we'd be happy to take those reports. :)

[xJon]

@malcolmdeck Thank you for the detailed reply. Regarding SMS auto retrieval, what would explain it not working with new versions of firebase-auth? In @hkchakladar's original post, you can see that the new SMS structure with the project ID is actually shorter than previously, yet auto-retrieval does not work - that cannot really be explained with character limits.

[malcolmdeck]

Yeah, I'm happy to address that. The relative size of the SMS contents between pre- and post-20.0.0 are a red herring - the mechanism by which auto-retrieval is done changed, so the character limit doesn't map between the two approaches.

[xJon]

@malcolmdeck I see. So what would one need to change in order to get the auto-retrieval working again post 20.0.0?
Also, it would be great to have reCAPTCHA still use the APP_NAME as it makes the SMS messages look much more professional - should this be opened as a separate feature request?
Thank you!

[hkchakladar]

Update: As per this https://firebase.google.com/docs/auth/android/phone-auth?authuser=0#enable-app-verification, I have enabled the Android DeviceCheck API and now the SMS is showing app name as earlier, but still OTP is not detected from SMS.

[efstathiosntonas]

In my case by using a device that had unlocked bootloader forces user to use reCAPTCHA instead of SafetyNet (expected flow) and the device receives an SMS with the project link instead of ... code for APP NAME and it never auto verifies the SMS, user has to enter it manually. (logcat shows LOCK_BOOTLOADER)

I've locked the device bootloader, the app uses SafetyNet, it receives the SMS with an APP NAME instead of project link and the auto code verify works as a charm (app won't open a web browser for reCAPTCHA). Exact sms message is:

223343 is your verification code for XXX.
<C11 HASH>

The SMS coming from reCaptcha does not include C11 hash, that's why sms auto verify won't work.

I get SMS expired complaints from many users though (don't know what their bootloader status is) while other users can login/register into the app just fine.

EDIT: while on unlocked bootloader, i've got this on logcat:
sms verify W/ArrayMap: New hash XXXXXXXX is before end of array hash XXXXXXXX at index 1 key 342543 is your verification code for XXX.XXX

[ZComwiz]

Regardless of reCaptcha or SafteyNet — reCaptcha itself is broken for Firebase on Android since BOM v26+

See firebase/firebase-js-sdk#4256 (comment) for the same exact problem: "Missing Initial State." Only solution was to downgrade to 25.13.0 to prevent firebaseapp URL SMS messages and totally broken SMS login flow that requires multiple retries and training GoogleAI to learn what a parking meter is.

Breaking Changes such as the now needed SafteyNet need a bigger flag in the change logs for developers and library maintainers to see especially when you are dealing with Auth Flow where a lot of it is guesswork as to whether it is working in production or if it is just a debug issue that will resolve when it is code signed on the PlayStore.

[kperreau]

Still an issue, got SMS but auto retrieval timed out.

NB: There is no App hashcode in my sms validation code.

Here is my logcat:

2021-03-04 19:45:37.209 31947-2157/? D/Auth: verifyPhoneNumber:+336********
2021-03-04 19:45:38.924 31947-31947/? D/Auth: verifyPhoneNumber:verification:onCodeSent
2021-03-04 19:45:58.305 31947-4314/? W/FirebaseAuth: [SmsRetrieverHelper] Timed out waiting for SMS.
2021-03-04 19:45:58.306 31947-31947/? I/PhoneAuthProvider: Sms auto retrieval timed-out.
2021-03-04 19:45:58.306 31947-31947/? D/Auth: verifyPhoneNumber:verification:onCodeAutoRetrievalTimeOut

Works fine with BOM 25.13.0 but broken since BOM 26.0.0.

[mikehardy]

This comes up from time to time on react-native-firebase and as I offer user support there I'm curious if there is any triage planned here? I don't know what to say to library consumers when they ask, but based on this issue traffic the reality appears to be "there is no current or planned forward progress for the regression on SMS auto retrieval for android". Is that correct?

[mikehardy]

forcing github to formally have the cross-link to invertase/react-native-firebase#4540 where we are tracking the OTP auto-retrieve regression with BoM >=26

[jjmutumi]

@samtstern, @malcolmdeck Is there any progress on this issue? Especially appending the app hash? I don't know if my math here is wrong but I don't see any limitations on character limits.

According to SMS retriever spec: SMS must not be more than 140 bytes / 120 characters

The fixed SMS template on Firebase is:

%LOGIN_CODE% is your verification code for %APP_NAME%.

In the recaptcha auth flow the APP_NAME is replaced with the project link:

LOGIN_CODE is your verification code for PROJECT_ID.firebaseapp.com. APP_HASH

The Firebase project name is limited to 30 characters. (https://support.google.com/admob/answer/6394788)

MESSAGE    = 43 characters
LOGIN_CODE =  6 characters 
PROJECT_ID = 31 characters
APP_HASH   = 11 characters
           = 91 characters

This is well below the 120 characters limit.

[mikehardy]

@jjmutumi 120 bytes, 30 characters, what happens as you expand multi-byte character sets from characters to bytes? If I understand correctly, that's the problem.

[jjmutumi]

@mikehardy sending SMS in UCS-2 format (multi-byte) limits the payload to 70 characters. If that's the concern then the message will be going over the max possible limit even without appending the app hash?
It would be nice if this could be fixed somehow?

[theJovian]

Can anyone confirm @jjmutumi and @mikehardy theory?
I am having a problem where in my test app the auto-retrieval is working fine but on prod is getting a timeout and the only difference I can make up is the fact that the message in the test app is shorter than the prod message, and after doing some maths using SMS in UCS-2 format as a reference, I can see that the prod message is greater than the limit of length where as the test message is inside the limits. But of course it is not trivial to change the %APP_NAME% to fix this problem, specially if it is not confirmed. So, can anyone help me?