Security Issue: User Impersonation

[softrsimon]

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.

[Ben]

Here’s an idea to improve email verification for external user sign ups. What do you think?

Sign Up Email Verification

So far, the only way to “verify” signed up email addresses involves workarounds (i.e. Sign In With Code block, Sign Up block with Airtable automations that send a magic link, or 3rd party integrators). All of which are no-code, but have significant drawbacks: Users cannot sign back in with the Sign In With Code block, because it doesn’t create a password for subsequent log-ins, yet still creates a user in both the Softr and Airtable Users tables Sending an automated Magic Link from an Airtabl…

[Ben]

Hi Artur. Any update on this? It wasn’t on the list of upcoming releases on the Business/Pro webinar last Monday.

[flavi]

Hi @Suzie,

Is this still on the radar?

[artur]

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.

[Ben]

@artur, email verification nor public vs internal sign up are on your roadmap.

[artur]

They are in… our product team is working on it, it still needs to go through review/design and then get into implementation…

[Ben]

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”.

[artur]

Let me share that feedback