Email verification system does not prevent users from signing up with emails they do not own

[clairep94]

Increasing Access

Prevents users from registering with email accounts they do not own, so that users who own the email accounts are able to register.

If we migrate to OAuth, the sign up flow for users should also be easier (one-click for new users, less memorization for passwords)

Feature enhancement details

Context:

@Geethegreat is working on the 2026 GSOC project to add E2e testing to the p5.js web editor.
As part of his work, he started writing a test for the "User sign-up flow".

He found that users who are registered, but unverified, can continue to use the p5.js web editor with their accounts.

This could mean that user A could sign up with an email belonging to user B, thereby preventing user B from signing up with their email.

This also results in easy creation of spam bot accounts.

Proposed Solutions:

We would either plan a migration to OAuth or add a re-direct to a "Please verify your account" page for users who are registered but not verified.

The latter looks easier, but we would need to figure out how to accommodate users who maybe registered with an email they no longer have access to & what to do with all stray accounts that do not get verified (do their emails become eligable for new users to register with after a TTL?)

[clairep94]

cc @Geethegreat could you add screenshots of your findings?

cc @raclim @khanniie

[Geethegreat]

Hi! Adding my findings and screenshots here.
While writing the signup E2E test, I noticed that after submitting the signup form, the user is immediately redirected to the editor and logged in, without needing to click the verification link in the email. I initially thought this might be a bug, so I investigated further.
Looking at createUser in server/controllers/user.controller/signup.ts, req.logIn() is called immediately after user.save(), before the verification email is even sent. This means login happens regardless of verification status.
I then searched the entire codebase for any checks on user.verified and found none that gate functionality. No server middleware, no route guards, and no client-side route checks verify the verified field before allowing access to editor features like saving sketches or accessing the sketches page.
The only place verification status affects the UI is AccountForm.tsx on the /account page, which shows an "Unconfirmed." notice and a "Resend confirmation email" button, but only if the user visits that page. A user who never visits /account would never know their email is unverified.
Screenshot below shows the "Unconfirmed." notice for an unverified account on /account:

This confirms what the issue describes, an unverified user has identical access to a verified user, which does open the door to the email ownership problem mentioned above.

[Geethegreat]

cc @clairep94, one additional finding worth noting: accounts created via Google OAuth are automatically set to verified: 'verified' in passport.js, so the "Unconfirmed" notice never appears for Google login users. This means the verification gap only affects users who sign up with email and password directly.