The standalone Google sign-in block is part of phase 1 (in my humble description) but phase 1 doesn’t work yet because, short of custom code there is not yet any way to prevent native sign-up.
I think how @dcoletta broke it down is a great approach. Softr already has an only Google sign-in block already, so I believe #1 is solved.
#2 is the way to fix this. It would be essential to have this as an option as we don’t want to reduce usability for less critical apps (I’m reading PLG now and saw a metric regarding email verification reducing usability). This is where #3 would be handy. I’ve seen apps allow you to login but with limited access until you verify.
If you remove the signup page, users have to sign in with a validated email, right? So wouldn’t that solve it?
But yes, I agree, having a better built-in way to do this is better.
At the risk of beating a dead horse, #1 is not solved today without custom code that blocks native sign-ups in the sign-up block. (Or as @alex37 suggests, don’t offer a sign-up block at all, and create accounts via the API or the studio.)
Hey @dcoletta, I’m referring to this block here, which I’ve used before. Maybe I’m missing something? (Poor horse! 
)
That block prevents native sign-in and only allows Google Sign-in. That’s half the solution. The problem is there’s another half that is needed, which is a block that prevents native sign-up and only allows Google Sign-up. That does not exist.
Arthur, native email verification would be a fabulous addition.
Here is all what I tried, none of them ideal from a user perspective:
I am currently trying to build a workaround using this solution (Internal apps and client portals: how to automate the user creation with Make.com), but this lacks feedback for existing accounts/emails.
Using the Softr “email signup block” has the risk of non-verified users on the platform.
I also tried to chain the “email signup block” with the “sign in with code block” but here the user groups (logged-in users) get in the way with forwarding to the next page and it’s impossible to match the verify email with the signup email.
The option to auto-generating the magic-link when a user is created (without MAKE) would also do the trick.
I thought about having them sign up with the “email sign up block” and then manually clicking “verify email” on the next page / profile. With action buttons and an Airtable Automation, this would work too.
Hope that helps.
Hey @softrsimon,
Just wanted to inform you that this is already in our todo’s. Here we just tried to suggest some possible workarounds for you to complete the setup but the option will be implemented natively,
We are working on a few big releases now, hope that after that the team will be able to focus on this feature.
2 Likes
I’m interested in something similar to what you proposed:
I thought about having them sign up with the “email sign up block” and then manually clicking “verify email” on the next page / profile. With action buttons and an Airtable Automation, this would work too.
I haven’t been able to figure out a way to make this work. If you were able to implement it in practice would you mind sharing how you did it?
I’m surprised this isn’t a higher priority feature, I don’t see it on the roadmap.
Hi, yes I got it to work. You can try the flow from the user perspective at climesumer.com.
Here is what I did:
- I use a Softr Form as the first signup and create a user in Softr using Make.
This tutorial: Internal apps and client portals: how to automate the user creation with Make.com.
This allows me to automatically create a user and store the magic link in my Airtable base. - Using an Airtable formula I append a “verify email page” (with a button) to that magic link.
- Using a status field (with verified, not verified) and views, I have an Airtable automation the gets triggered when a new user is created.
An email is sent to the new user with the magiclink+verify_page. - When they click the link they get directed to a verify email page. That page has just one button which actually is a form with hidden fields, recording the user name.
When clicked, it changes the user status field to verified.
That’s it.
Hope it helps. Let me know if anything is unclear.
1 Like
Thanks for this response. I have changed step 4 with a “List details page with side image”. The block only contains a one click update.
I am concerned with ‘URL hacking’ of non verified users. such as once users know that the url is www.domain.com/verifyme then they could just bypass the email step.
It might be worth building a make or airtable automation that updates the field to verified on button press. Would love to see if anyone has came up with anything new since.
I think this process is safe. When they click on the link, they are automatically logged into Softr.
The confirm button also records the logged-in user who clicked the button.
I only show this block to logged-in users, non-authorised users won’t be able to see it. Even if they could click it, it would log anything, and they would just see empty values.
Here’s an idea to improve email verification for external user sign ups. What do you think?
1 Like
Hi Artur. Any update on this? It wasn’t on the list of upcoming releases on the Business/Pro webinar last Monday.
Hey folks, we are now revisiting the whole user registration workflow where we will have invite-only and/or public apps, and for public apps, we will be including email verification as an option.
They are in… our product team is working on it, it still needs to go through review/design and then get into implementation…
Thanks for clarifying @artur, it is indeed listed. How useful this is for builders’ planning, is not even a question anymore though, at least from many in the community. We simply can’t plan or do anything useful with “Later”, let alone “Next”.
Let me share that feedback 