Not sure where to post this, and frankly not sure if it should be in a public forum, but I realized an issue today.
Issue: Because users do not have to verify their emails (nor is there an option to), then any user can enter another user’s email (or domain!) and get access to that entire user’s records.
Many people have conditional filters to limit records to a particular logged-in user’s domain or email address. Not sure if this is a known issue or what (tried searching), but as a security company creating a portal for clients it would be disastrous if clients had access to other client’s data and reports.
Fix: Enable email verification for all email signups by default. Allow users to remove (but give a warning). As a workaround I can force Google auth only, or utilize Auth0 or something (more work).
The scenario you raise is interesting. Certainly having email verification in all cases would be ideal.
However, in order for this scenario to constitute a risk, it would imply that a user with that email previously exists in the database, so that it can have associated records, otherwise, it would be a new user without any record in the database, which implies that there is no risk.
Of course, if a new user comes and tries to register with his email (that was used by someone else), Softr will tell him that a “User by given email already exists.”, so he will not be able to use his own email to register.
Even if a user wants to change his email with another email of an already registered user, to try to “usurp” his identity, it would not be possible.
You can do the following test:
1) The user base is synchronized with Airtable. ( Note that the synchronization with Airtable is only from Softr to Airtable and not vice versa). 2) There are two users in the base:
User A with email: a@a.com
User B with email: b@b.com 3) User A enters a page that has a form where he/she can view and update his/her profile data, including email. 4) User A enters and tries to update his email to: b@b.com
Result: the user A’s email is not updated, it is still a@a.com
If I am not mistaken, it is not possible to have users with the same email, since it is the primary key that univocally identifies the user, therefore, the usurpation of identity could not happen.
Please let me know if there is something I have not understood in your approach.
So the problem is where someone is allowing any user from the the domain “acme.com” for example to access Acme’s records, based on the domain criteria.
However, a subversive user can easily register for an account with “attacker@acme.com” and is automatically granted access to Acme’s records, without any verification at all. Of course knowledge of the registered domain is required, but that can be pulled from the list of clients on a website, forum, or any other public messaging.
Does that help illustrate the risk a little more clearly?
Perhaps one option was to use the Signin with Code block., but I understand that it is not useful, since it is the Signup process that would have to be validated initially (email verification).
Just to clarify the force-Google-auth scenario: you can force Google auth by building an app that uses only the “Google Sign in” and none of the sign-in blocks that offer sign in with username and password.
However, the only way to prevent signing up with username and password is to use custom code to hack the fields out of the Sign Up block.
This is particularly pernicious, because it opens a social engineering hole: if the user can sign up with an unverified email, then even if they cannot log in, they can email the admin, spoofing the From: address of the email, and request a magic link, and then it’s game over unless the admin is really careful. If the attacker is really good they won’t even ask for the magic link, they’ll just keep saying they can’t get Google Signin to work until the admin thinks of the magic link feature and sends the link unprompted.
Hey folks, thanks for bringing this up and we should certainly prioritise email verification. I think @ayman point is specifically valid if one has open registration to a platform and does gating based on the domain only. I will talk to a team to enable email verification.
I think signup blocks that have email in them could have option to enable email verification in them where immediately the next step step is to verify email… wdyt ?
Yes that could work, I also think there should be a new user group or subgroup, next to logged-in users;
Verified-users, then we can save time planning logic for content for non-verified users and put a little pressure on them to make them check their emails to verify and gain full access to content.
The most urgent thing is to close the existing hole in Google auth integration by creating an option in the Sign Up block to permit only the “Sign Up With Google” flow.
The next most urgent thing is to allow the sign-up flow to pause for email verification and only allow the user to log in after that is complete.
Finally, I think it’s important (but not urgent) to support the use case where an unverified user can still log in but is restricted (e.g., with group-based permissions) from some areas of the app.
You could probably convince me that 3 was more urgent than 2, but I suspect 2 is a lot easier to implement than 3.
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.
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.)
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.
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.
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.
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.
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.
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.
Note that the synchronization with Airtable is only from Softr to Airtable and not vice versa).
)