Does anyone know if it’s possible to connect Twilio for account verification where it sends a text message to the users phone which must be inputted into your app in order to create an account?
1 Like
Hi,
that’s a really interesting idea.
I don’t know how to do it, but you should check Zapier.com. It’s a tool that connect apps. It’s compatible with both bubble and Twilio, that’s where I would start looking, I bet you can make what you want from there.
If you manage to make it work post here how you did so we can all know.
There is no official account verification workflow, but we use Twilio to verify phone numbers (that end up verifying an account) using standard Bubble capabilities.
First, we verify email address. Then, upon logging in following that first phase of verification we show a popup that prompts a person to enter a phone number for further verification. We ask if they want SMS or voice/call verification. In a workflow we create a random new 6 digit number variable in a field on the user called phone_verification_code. If SMS is selected, we send a text with Twilio to confirm (they are sent the code, and must enter it next — it must match the code assigned to that user profile. We allow 3 attempts per phone number per 24hr period to prevent abuse. If voice/call is selected, we use Zapier to send a text-to-voice message to that person. Same as SMS< we limit this to 3 attempts per 24hrs.
After confirming the account with SMS we toggle a boolean variable “sms_verified” to yes and save the number and do a few more things to allow notifications for that device.
This has worked great and covers almost every scenario we’ve come across.
10 Likes
How do you set the 24 hour limitation logic exactly?
One way to accomplish this is increasing a counter variable on the user ‘verification_attempts = current user’s verification_attempts + 1’ upon each SMS verification attempt. Then on subsequent attempts you simply check this value. If the value = 3 already (aka 3 attempts), set a timestamp variable on the user ‘verification_next_available = current date/time + 24hrs’ — using conditional statements you can disable the input fields/submit buttons/etc (that you created for the SMS submit interface) ‘IF verification_next_available >= current date/time THEN disable inputs/buttons/etc’. I hope this is clear, my workflows for this are all over the place and not very easy to share or screenshot.
Edit: forgot to mention that you will want to clear both ‘verification_attempts’ and ‘verification_next_available’ when an attempt is made and the 24hrs has lapsed.
4 Likes
Brilliant, this helps a ton.
At last, everything works fine now. I created a seperate Thing to store Authentication data (Password, User, Token, verification_next_available, verification_attempts) and use Twilio to pass a temporary verification code.
I noticed in the documentation there is an emphasis on using reset_pw?reset=[LONG_ID] page for password resets. Are there any security advantages to using the built-in tokken system vs our custom route?