Verify User, Email verification - Free

[Adalotaco]

Goal of this Tutorial:

Person registers with an email they have access to and verifies access to the email.
All of this is handled without third party resources

Step one is the Registration process.
Move the password option to the Set Automatically section and use magic text
Scroll all the way through your options for magic text until you get to the ‘New Formula’ option
A Bubble that says ‘Custom Formula’ will show - we will now edit the custom formula.

Choose RAND() as the formula function. We set the numbers between 10000 and 999999 (again, it’s temporary)

We will use a simple formula because we’re setting a temporary password and it won’t be permanent.
You must set something in the password field, it can’t be blank, so this is the simplest way to fill that temporarily.

Once they complete the registration form, they go to the ‘Verify’ page, You’ll need to make this page, of course, which is simple enough.

Step Two: Verify Page
On the Verify page, you have one action set to the page - Log Out.

The log out step is important because if they close out the app and open it, they’ll be logged in without being forced to do anything else with their password.
You are having the log out function immediately following the account creation.

And then you have an action set to a button - Set Password.
This will prompt them to enter in their email again - the system sends them a temporary password, they log in with the temporary password and the system goes through the motion of prompting them to set the password they actually want.

Since they haven’t already set a password, they know they need one.

Of course, this is now using an adalo system function and email.

They will go to their email and they will get this temporary password - and log into the app.

When they log in with the temporary password, the adalo system then prompts the user to set their own password.

In the event that they do NOT set a password, they are already logged out.
If they abandon the set password option to try to force close / restart the app, because they want to get access without a real email, then they will already be logged out.

To proceed, they have to use the ‘forgot password’ function, which again requires the exact same process for them to gain access to the app.

While this is a bit clunky and heavy handed as far as requiring verification, this prevents the need to track, send, and verify temporary passwords through a variety of screens and actions yourself. It relies on Adalo to do that - as it should. The temporary passwords also expire after 24 hours.
If you don’t like the RAND option for the temporary password, feel free to use literally any random generated text as it is temporary.

I know this isn’t the fanciest solution and it relies on adalo’s internal password management systems but hopefully this is simple enough for anyone to follow and use.

Was this Helpful?

• Yes
• No

[Yongki]

Hi @Adalotaco ,

While it seems to work with few more tweaks.

Are you using this for your own app with real users ?

The UX will confuse users, not to mention it will abuse forget password function.

[Adalotaco]

I’m surprised at that anyone would assert that this would be abusive of a feature, given that it would be the same result if I were to set my own random generated codes - and would then send those emails with the ‘Notification - Email’ option.

So that, I take offense to.

If it’s a legitimate use, a use that should be built in and not need to be manually built out with multiple steps and pages or external services to verify, then it’s not abuse.

Now, if I were someone tricking users or using this to actually harm people, that would be abusive.

Otherwise, Adalo needs to get with the times and start making more efficient processes and features available. And as of recent announcements - I’m paying for all these actions anyway (at least I will be).

Yes, using it with real users.

And while it might be clunky, as mentioned, it’s not going to confuse people.
Everyone expects to set a password, to verify their email, etc.

As long as the process is in a linear fashion, then it should work fine.
If they get confused at any point in the process then they circle back to ‘your password is wrong’ followed by ‘use forgot password’, and they take the steps I want them to take.

[Yongki]

I will not argue as it seems you already figured it out all the reasons of why and why not.

Good luck.

[Adalotaco]

I did my best to explain my logic and reasoning behind the entire process, start to finish.
How the user will experience that journey, where there could be user missteps (forcing close on the app causing problems in verification process, etc), and why each step was selected at that stage for those reasons.

I am seeing a need for well documented fixes and solutions, even simple ones. Even imperfect ones.

Instead of building out 15 steps to verify a person actually has access to the email they are signing up for, this offers a solution with fewer steps and services.

Honestly, it should be built in. Email verification to make sure you’re not getting spam signups should be standard in 2022.

Best of luck.

[Flawless]

This is pretty similar to the tutorial that I put together back in April: How to verify a user's email address upon registration using Adalo - YouTube

However, there is a huge security flaw in this method. Users can locate the randomly generated number in the “Network” tab of the Inspect console.

This method is not secure as the code can be grabbed through the app without the user actually owning the destination email address.

Per @Mitch-Pragmaflow’s recommendation, it would be a better idea to generate the code outside of Adalo. Like you can use Make when a user signs up and generate the code within Make, then send the user the email. That way, users won’t be able to find the code that you generated in the inspect console.

[Adalotaco]

I followed your link and watched your tutorial. I guess you were just looking for a reason to spam a link to your own promotional tutorial (with affiliate links, links to your site & paid mentorship, etc) because I see absolutely zero similarities. Which is rude.

I would welcome Mitch’s feedback.

This is an email verification for general use.
This tutorial is using the password field of adalo, not a plain unencrypted text / number field in the database to store a verification variable.

As far as security goes, simple is better.

Also, the number of actions and pages this requires is low.
It reduces the extra columns needed to be in my databases (and the variables it would store, probably forever, adding to bloat). Which, given the direction Adalo is going, means my method is cheaper on an Adalo plan at scale.

And doesn’t require multiple external paid monthly services to get it to run.

Anyone that can grab the rand() function from the network / inspect console is smart enough to be able to use a throw away email for verification. This isn’t an Auth0 replacement. This is a simple email verification to make sure users are not using nonsense email addresses they don’t own.
The majority of users, this will force them to verify their email effectively. And efficiently as far as my app goes.

[Flawless]

This method is insecure. And here’s the proof.

@Adalotaco

I followed your link and watched your tutorial. I guess you were just looking for a reason to spam a link to your own promotional tutorial (with affiliate links, links to your site & paid mentorship, etc) because I see absolutely zero similarities. Which is rude.

The similarity is that there is a randomly generated number using RAND function, which can be accessed by users.
To call my comment rude… is actually rude. I commented to point out a major security flaw in your operations, the same flaw that is in my tutorial video. My comment is aimed to assist you, not to promote myself in any way, shape, or form.

@Yongki and I are Adalo Experts and Community leaders for a reason, my Taco friend. We want to help you and we have vast amounts of experience. We are not being rude. Be open to our constructive criticism.

Watch this quick screen recording and you’ll see that a user can easily access this randomly generated number that was set as their password.

[Adalotaco]

Addressing your demonstration:

The step immediately following the log out is the prompt to set their password, which most people will perform when prompted.

This is also not relying on a plain-text variable being saved in a database which is less secure than a random number generated in a password field and the user flow being designed for that to be temporary - as in, less than a few minutes, maybe an hour if they are tech challenged, one would hope.

Your video was unsecure at a different level because you’re dealing with plain-text variables that are not [hidden] when the data is handled. You know, as long as we’re digging into the details of worlds-most-pita-users. I would rather a user be able to see their own credentials on their side, than to have an entire database of password-like variables open to exploit because they’re not in a password field in a database. Even if it is just email verification, which isn’t the only element of security in an app, I hope.

It’s true that people could jump through these hoops (certainly with PWA, though I’m not sure about native mobile) to circumvent the email verification process during registration.

However, a person going through this amount of trouble to get access to an app that simply requires email verification is going to only be accessing their own credentials.

I’m not putting all my users at risk for exploits - and paying monthly fees on top of it to make it work (send grid, the other service you mention, the increasing adalo use-fees), with multiple layers of actions/steps to verify, which are less than ideal for the user experience if the conditions set on those pages break/falter. And does not scale. (Scale is everything, running light should be every dev’s goal)

If they type in their own password, it will reveal that to them also in plain text. This is not specific to using the RAND() function. (in case that isn’t clear).
But currently, there is no email verification process in the Adalo registration process.
The difference is - a few people game this, versus leaving it open for ALL people to game the registration process because there is no email verification natively built in.

The option I’m presenting is more secure than the native solution, but not less secure than the free options already on offer in this forum.

I do acknowledge that it has a momentary security weakness - but all data has weak points. The goal is to minimize them and limit the ramifications if you have someone intercept some of that information.

One variable at risk, their own variable, fine. I can isolate that user.
Additional variables in the database that are given authentication-like credentials that (the random generated numbers saved and then authenticated through sendgrid / back to compare with the database entry, etc) is bloated and less secure because it has more moments where it can be intercepted and abused.

The random generated number in my example / tutorial is not a permanent password.
It’s handled securely as a password, as it is in the password field, by adalo.
And the system then immediately signs out that user - and prompts them to immediately set a password.
In theory, that random generated number should exist for less than a few minutes. And still takes less time than your method of authentication - waiting for a very long time for adalo to trigger their APIs and get the verification email sent. That’s a lot of users dropping off.

It’s about choosing what is more efficient, scalable, and as secure as possible.
Fewer steps, fewer opportunities for abuse (interceptions / changing data / data injections).
Nothing is going to be impervious to security issues or possible abuse.

I feel like this was a great chat.
I stand by everything I’ve said here.

[Adalotaco]

@Flawless

This is pretty similar to the tutorial that I put together back in April: How to verify a user’s email address upon registration using Adalo - YouTube

However, there is a huge security flaw in this method.

This is not the same as ‘I have a tutorial that got called out for this same security flaw’. (it’s not the same flaw, yours is exposed plain text)
In which you didn’t link to the forum discussing that tutorial, instead your youtube video with your links etc.

But okay

[Flawless]

It’s literally the exact same flaw. If you watched that recording, you’ll see the password, clear as day. Regardless if its in the password parameter, text parameter, or number parameter of the user collection. Its the exact same thing.

[Adalotaco]

The user can, with inspect, find out the randomly generated number set for their password field.
Meaning, only their OWN randomly generated number.

However, if my database is compromised, absolutely no variables are stored outside of a hidden password field. Not even temporary email validation numbers.

Yours would be revealed for all users if you had a breach.

Everything you did - handling the data in your database, reveal password, adding additional API requests and passing data between them in plain text, this is the added security risk.

If you don’t understand how to see the differing levels of risk, I don’t know what to tell you, expert.

If you don’t understand the benefits of reduced pages, actions, and variables in a database to make it more efficient and streamlined, again. I don’t know what to tell you.

Carry on.

[Flawless]

Not to worry Taco. I will refrain from providing any insight or assistance to you in the future. I’m only here to help and you apparently don’t want the help.

I wish you the best of luck.

[JL_LJ]

Hi @Adalotaco ,
I understand you have a different approach, I also use my own method for authentication (SImilar to yours and @Flawless, but using https://passwordwolf.com/). But no need to get stressed, we are here to debate, share different opinions, and we use the ones we like or believe work best for us. But no need for offenses, these are good guys, that took time to analyze your topic and to just offer a counter-proposal which my opinion is great since we all have different ways of thinking.
You don’t need to accept the solution, but let’s keep the offenses out of the forum please. In any case, we are here to provide support to everyone. Experts or not .

[paulh]

@Flawless would this be an issue if app is native only, no web access?

[Flawless]

Good question. To be transparent with you, I’m not 100% sure.

I would imagine if it’s possible on a computer, it’s possible on a phone.

[JL_LJ]

To help out @Flawless here, the info is passing on the browser, if you run as an app, regular users have no access to this, but Android/iOs tech savvies would probably get access to this (You can actually also run apps in Windows for example, there are programs for that).

I would say the issue in web apps, relies in seeing the information flow in the browser via the network console, so using public networks, shared computers to access web apps, exponentiates the security risk, but using your own computer and mobile, you should be in a comfort zone and exposed to risks “business as usual”.

One option for Adalo to potentially fix this code flows as we like to setup secret passwords, would be to use cookies with choice for the expiration time and in which screens, so once user would login, that “secret” would expire or keep open until we set a session expiration. That is how I at least do in other No Code tools that allow it.

Another one I remembered, limit sessions to one Instance (Mobile, computer) or via IP, same session in 2 different IPs, would be a red flag.

[terrellp]

Does this free method work? I know the other methods work, but I don’t like the additional steps and services. I can image the security concerns are low risk if the intended users are not tech savvy. I would love to implement the free method if it indeed works. Any insights from the professionals here? I’ve only been with Adalo for a few weeks.

[Rozza]

I would highly recommend a Xano backend. But if free is the most important, and security doesn’t matter, then yes.

[terrellp]

Thank again Rozza. You’re pretty active on here I see, thanks. Do you know any freelancers? I’m thinking of turning the webapp into a subscription native app and would like someone to do the IAPHUB connections and uploads to IOS/Play store.