Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Email verification #8240

Open
FelixMalfait opened this issue Oct 31, 2024 · 6 comments · May be fixed by #9288
Open

Email verification #8240

FelixMalfait opened this issue Oct 31, 2024 · 6 comments · May be fixed by #9288
Assignees
Labels
for experienced contributor scope: back+front Issues requiring full-stack knowledge

Comments

@FelixMalfait
Copy link
Member

FelixMalfait commented Oct 31, 2024

In the future, we're going to open a generous free plan on the cloud version, so we need to limit the number of spam accounts created.

Let's introduce email verification for people that don't use Microsoft/Google login.

Pre-requisite: introduce a server-level environment variable IS_EMAIL_VERIFICATION_REQUIRED (defaults to false), as some people self-hosting might not want to go through that (means they have to setup an email server!).

Signup Process

  • Set isEmailVerified to false initially (already the case)
  • Generate a unique email verification token.
  • Store the token in appToken
  • Send Email containing the verification link
  • Create a page to handle verification requests, which sets isEmailVerified to true and then automatically login the user

Note: users joining an existing workspace through an invite shouldn't have to validate their email again

Signin Process

During signin, check the isEmailVerified field.
If isEmailVerified is false, prevent login and prompt the user to verify their email.
Optionally, offer to resend the verification email.

Note: we already have the emailVerified column on user but it wasn't used - we might want to drop it or rename it to isEmailVerified to be consistent with other columns in the codebase
Todo during deploy: script/sql query to set emailVerified=true for every user that ever had a valid subscription (credit card = strong verification, we can consider the email is most likely to be valid)

Email content

We already have templates for Twenty emails (e.g. user invites)

image

https://www.figma.com/design/xt8O9mFeLl46C5InWwoMrN/Twenty?node-id=44465-119474&node-type=frame&t=L4Zw8NIeonoYkIdd-11

@Yashgupta9330
Copy link

I want to work on this issue can you please assign it to me

@FelixMalfait
Copy link
Member Author

Sure thanks @Yashgupta9330!

@samyakpiya
Copy link
Contributor

Hey @FelixMalfait,

This seems like a feature that'd be fun to work on! Could I be assigned?

@FelixMalfait
Copy link
Member Author

You're everywhere @samyakpiya 🐐 - thanks!

@samyakpiya
Copy link
Contributor

samyakpiya commented Dec 31, 2024

Hey @FelixMalfait,

I understand we’re planning to allow account creation first and then send a verification email to restrict login until the email is verified.

While working on the issue, I was thinking about instead sending a verification code that includes a magic link right after the user enters their email, before they set up their password. This could help reduce spam accounts, save resources, and enhance security.

It seems we already have the template for it.
https://www.figma.com/design/xt8O9mFeLl46C5InWwoMrN/Twenty?node-id=4162-56741
Image

Optioanally, we could create an Input OTP frontend UI component for it.

Let me know your thoughts!

@FelixMalfait
Copy link
Member Author

@samyakpiya we wanted to implement no-password + magic-link only initially, but then we asked for user feedback and it seems magic link isn't as popular these days, most people want a password.
I understand your proposal is to keep a password-login but defer password creation to post signup, which would work.
I think the "save resource" argument would have made a lot of sense if we had workspace schema creation directly upon signup but that's already differed, I don't think not asking for the password would make things structurally different.
So I would say from a UX perspective I agree your proposal is probably a bit better, but it's not probably not worth the added eng complexity of introducing a variation to the flow. Let's go for the simplest/most elegant eng implementation

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
for experienced contributor scope: back+front Issues requiring full-stack knowledge
Projects
Status: 🆕 New
Development

Successfully merging a pull request may close this issue.

3 participants