In this Bubble tutorial video, I'm going to demonstrate to you how to generate a verification code for your users and check that verification code in a secure way.

Don't generate verification codes in the front end!

The trouble is it can be really tempting to generate this code in a front end workflow. But this means that with the browser developer tools and a skilled user, they could access this code, regardless of whether they receive it via email or SMS, therefore, making it basically useless and completely and secure. So I'm going to demonstrate to you how you can use a backend workflow to securely check a verification code without the user actually getting access to that code.

So to do this, I've got a simple form set up here where I'm going to enter an email address and then a form to check it. And I'm running my app and I'm logged in as one of my users. In fact, I'm going to add in a text label here, current user email one, so that that's really clear what's going on. Refresh that. So you can see that I'm logged in as a demo user. And in fact, what I can then do is start creating a workflow for when this button and send is clicked.

Could you use a Magiclink?

Now, remember that Bubble actually includes a number of prebuilt abilities to do something similar to what I'm going to demonstrate here. You can generate Magiclinks using a Magiclink workflow action. You can verify an email address using an existing template in Bubble. So there's no need to create unnecessary work and potentially additional security flaws if you're trying to do Magiclinks or you're just trying to verify an email address. This is if you're wanting to add an additional level of security or you're simply just wanting to generate a code and check that code against the user based on whether they've received that in an email or they've received it in an SMS.

Generating a verification code with backend workflows

So I'm going to demonstrate how to do that with an email. So we need to create a new workflow, and we then need to go into backend workflows and create a new workflow. And we shall say generate and send code. It's not going to be public. And into this, we're going to pass a user. And what we will do is we will generate a unique six digit code and save it to the user. So we will go for make changes to current user and we'll say verification code of type text.

And then we'll go calculate formula generate a random string, number of characters, six, use numbers, six digit codes with numbers.

Updating privacy rules

But we need to protect this because, again, we don't want the user to access this simply because they're logged in. So we'll go into data and we'll go privacy rules and user. And we'll untick View All Fields so that the user can only view the essential fields. Some of these ones are previously set up. Basically all but verification code, because we don't want the user to actually be able to view the code. So make changes, generate the code. This is done on the backend, so the user can't view this work flow step. And then we will just send an email. No, not that one. Just the regular, send an email, and we'll send it to user email.

Now, I've a little bit messed things up here because here I'm a flow into current user, whereas here I'm sending to the user that I'm placing into the workflow. Now, because the user who is trying to get through this verification step, they are current user and they trigger this workflow directly, they are still current user from the perspective of this workflow.

So I could actually here say current user email. And then I'll say here is your code, and I'll say current user verification code. Now, I'm not sure that that is actually going to be accessible unless, of course, I say that privacy rules are ignored in this because we can write data into a field that we don't have read access to. But then we actually require reading the field when we get to this step. So I think this is better run. Although the precaution should be used when tick in this box, ignore privacy rules when running the workflow, I think we need it in this instance. And so that's going to send an email with the verification code. And to link that up to the front end, we add in a workflow action and we go schedule an API workflow, generate and send code. Schedule date, we'll just send it right away. And then the user is current user, although we've actually ended up not needing that field because we've just referred to current user throughout in the backend workflow. Now, I'm going to skip a lot of steps here. You'd want to provide visual feedback.

Checking verification code

You'd want to provide a prompt, say, check your inbox, wait five minutes, that thing. For time, I'm going to skip that and move straight on to how we would verify the code. So when it's verified, we will want to run another backend workflow. Again, we have no way of checking the code unless the user can read the code, so we have to run it in a backend workflow. Whoops, not that one. Backend workflow. And so we shall say, check code. And again, we want to run it without privacy rules. And this time we will need to pass in user. Or do we? We can still run it as current user, but I think we can run it as current user. Let's just try that. And so we shall say, make changes to a thing. No, make changes to current user. And we'll say verified, yes, no. And we'll say they're verified, yes. If a field here to pass the code in. So we will say code is text, and then we'll say only when code is current user verification code. Okay? So I'm having to create an additional field which is accessible to the user, verified.

In fact, if I go into data, I'm going to need to make it visible now. Remember, verification code is not visible or readable to the user. And so this step will check the code and change it to verified. So I can add in some visual feedback on my page. So I can add in the text here and I can say, current user verified. And if I preview that, in fact, I should have saved a form of this text that will say verified, not verified. Okay, so it's printing not verified. So let's test this. In actual fact, the way I've set this up, I don't need that input. So we'll click Send. And so the backend workflow for generating the code and sending the email is now triggered. And we can check that by going into app data and seeing that the verification code is there. Now, we as the app creator or as an editor can view this. But in fact, we will really thoroughly test my plan here. I'll say current user verification code, and we'll check to see whether that is visible. Hopefully, it's not. Yeah, it's not visible. Okay, so then if I go into app data and I copy the code, I can paste it into the field here, click verify, and make sure that my button verify is clicked actually runs the workflow.

I forgot that. So we run a schedule API workflow, check code, we run it right away, and we put in the input code. So it's running the backend workflow, and you can see now it's changed to verified. And although it is running a backend workflow, it is almost instant.

So again, you'd want to add in some visual clues and visual queues of what's going on to help your user to avoid them having to, say, spam the button, and then they get 10 verification codes in their inbox. There's lots more to cover. But I simply wanted to highlight the fact that this needs to be run in the backend workflow, and you need to have those privacy rules established so that the user with the browser tools with a little bit of skill can't access the code and therefore make the whole sending of it, whether email or SMS, completely null void, pointless.