App Id = B6910C73-9107-4391-9577-973980D01151
Hello, I cloned an app recently and can’t get the login flow to work as in the original app. It uses the registration/login flow as described in the Twilio Integration Plugin blog and the original has worked flawlessly for a long time. I’ve examined all settings I’m aware of side-by-side and see no differences. There are no logged errors. The Twilio Test Configuration passes, and I am able to send text messages just fine.
But logins behave differently in the clone: As described in the blog, I call the register function passing only a user name. But the service does not return a transactionId in the response, it errors out with a “Password required” error. But the user account is created! If I try to register again, it errors out with “User with that identity already exists.”
I am able to see the configuration details of the Twilio service in the console of the cloned app, but the settings button is disabled in the original app, so that’s the only thing I can’t compare. Any ideas what else I can check, please?
Thank you! Kelly
Hi @Kelly_Oglesby ,
Please create a test user account and provide us with access so that we can try to call your service, reproduce the problem, and then solve it.
Regards,
Viktor
Viktor, there isn’t a service involved. In a mobile app, I’m simply calling the UserService.register function, passing only a phone number. For two years, that’s been returning a transactionId, which the app returns with a password, creating the account.
In the clone, however, the call to “register” fails with a “password required” (3011) error, but the user account is added to the user table. It’s not doing the phone verification part.
Thank you, Kelly
Hello @Kelly_Oglesby,
since March 2022 we have modified the service code to allow per-user configuration for login with a phone number. That’s why your new app works differently now. You need to create a new column in the Users table with the name smsCodeAuth of Boolean type with default value True:
When registering a user, pass the value of smsCodeAuth along with the user object.
The service now has two new methods: enable2FA and disable2FA which you can use for enabling/disabling 2FA on a user basis.
Regards,
Stanislaw
Stanislaw,
In the cloned app, I added the smsCodeAuth field as a boolean with a default of “true”. The register call still fails with the 3011 error, and no transactionId is returned. However, now at least the user account is NOT created for a user that hasn’t been verified.
I’m a little confused - The smsCodeAuth field does not exist in the original app, and yet the call to UserService.register performs phone verification correctly, returning a transactionId.
As this has been in production for a while, I can’t pop in the change to the register call you mentioned. I hope that’s not what is keeping this from working!!???
Thank you, Kelly
I’m a little confused - The smsCodeAuth field does not exist in the original app, and yet the call to UserService.register performs phone verification correctly, returning a transactionId.
Because the original app has different service code than the current one.
As this has been in production for a while, I can’t pop in the change to the register call you mentioned. I hope that’s not what is keeping this from working!!???
It is.
If you can’t change the logic of the register call in your app, we can deploy the old version of the Twilio service into your app and everything will work as before in the original app. Would you like us to proceed?
Regards
I’ll think about this. Sorry, two more questions:
-
If I add the flag to the register call for the cloned app, I’d have to release the change to everyone.
Would the presence of the smsAuthCode flag break for users of the original app?
-
Doesn’t adding the flag in the mobile app transfer part of the security flow into the client, leaving a security hole? It seems would be very easy for a malicious user to bypass the phone verification by intercepting the setting and changing it, say in the debugger. I kind of like having the entire registration flow and logic opaquely residing on the server.
Thank you, Stanislaw
Would the presence of the smsAuthCode flag break for users of the original app?
No, it will not affect the original app logic.
Doesn’t adding the flag in the mobile app transfer part of the security flow into the client, leaving a security hole?
This flag is passed only during registration. The main idea behind this is that some customers may want to enable or avoid setting up a 2FA during registration. Afterward, they’re able to enable or disable it for themselves (if you provide them with such functionality).
But when logging in, the smsAuthCode flag should not be passed (and will be ignored if they pass it). It will be taken on the server from the database.
So, it does not lead to a security hole.
Regards
1 Like
No need to do anything further - I’ll figure out a way to add the flag to the client. Thanks for everything.
