Skip email verification for users invited via email.

JakeLoew · 2024-12-04T23:57:05.457Z

In my app, users can invite someone to join their organization via email. I’d like to make it so that invited users don’t have to verify their email address once they sign up, as they have already clicked a link in their email. After doing some research, and reading questions posted in this discord, it seems like this is not supported by wasp. It seems possible if I could generate an AuthIdentity and verification token at the time the invitation is sent, then add the token as part of the link sent in the invitation email and verify it when the user lands on the page I link them to. I’m just not sure how to make the ends meet. Any insights? Using the SaaS template. Wasp version 0.15.1

K

kapa.ai•12/4/24, 11:57 PM

Hi @JakeLoew. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:

K

kapa.ai•12/4/24, 11:57 PM

----------------------
Based on the provided knowledge sources, it appears that Wasp does not currently have built-in support for skipping email verification for invited users. However, I can provide some insights on the current email verification process in Wasp and suggest a potential workaround.

Wasp's email authentication system includes an email verification flow by default. As mentioned in the Email Verification Flow documentation (https://wasp-lang.dev/docs/auth/email#email-verification-flow), Wasp requires the email to be verified before allowing the user to log in. This is done by sending a verification email to the user's email address and requiring them to click on a link in the email to verify their address.

While there isn't a direct way to skip email verification for specific users, there are a couple of approaches you might consider:

Development Environment Workaround:For development purposes, Wasp provides an option to skip email verification entirely. You can set the `SKIP_EMAIL_VERIFICATION_IN_DEV` environment variable to `true` in your `.env.server` file. However, this applies to all users and is not recommended for production use.
Custom Sign-up Action:You might be able to implement a custom sign-up action for invited users. The **Creating a Custom Sign-up Action documentation** (<https://wasp-lang.dev/docs/auth/email#creating-a-custom-sign-up-action>) shows how to create a custom sign-up process. You could potentially modify this to handle invited users differently.

Here's a high-level approach you might consider for implementing your idea:

K

kapa.ai•12/4/24, 11:57 PM

When sending an invitation, generate a unique token and store it in your database along with the invited email address.
Include this token in the invitation link.
Create a custom sign-up page/route for invited users that accepts this token.
In your custom sign-up action, check if the token is valid. If it is, you could set
```
isEmailVerified: true
```
isEmailVerified: true
```
isEmailVerified: true
```
isEmailVerified: true
when creating the user:

const newUserProviderData = await sanitizeAndSerializeProviderData<'email'>({
  hashedPassword: args.password,
  isEmailVerified: true, // Set this to true for invited users
  emailVerificationSentAt: null,
  passwordResetSentAt: null,
})

const newUserProviderData = await sanitizeAndSerializeProviderData<'email'>({
  hashedPassword: args.password,
  isEmailVerified: true, // Set this to true for invited users
  emailVerificationSentAt: null,
  passwordResetSentAt: null,
})

const newUserProviderData = await sanitizeAndSerializeProviderData<'email'>({
  hashedPassword: args.password,
  isEmailVerified: true, // Set this to true for invited users
  emailVerificationSentAt: null,
  passwordResetSentAt: null,
})

const newUserProviderData = await sanitizeAndSerializeProviderData<'email'>({
  hashedPassword: args.password,
  isEmailVerified: true, // Set this to true for invited users
  emailVerificationSentAt: null,
  passwordResetSentAt: null,
})

Please note that this is a conceptual approach and would require careful implementation to ensure security. It's also important to mention that modifying the core authentication flow might have implications for security and user management that you should carefully consider.

For the most up-to-date and accurate information, I recommend reaching out to the Wasp team directly through their Discord channel (🙋questionsdynamic variables in main.wasp) or creating an issue on their GitHub repository (https://github.com/wasp-lang/wasp/issues). They might be able to provide more specific guidance or consider adding this feature in a future version of Wasp.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------

K

kapa.ai•12/4/24, 11:57 PM

Sorry @JakeLoew, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist:

Perhaps try again in 15mins?

M

martinsos•12/5/24, 9:45 PM

PInging @miho he is the master of auth, might take him a bit since he is on a conference though

J

JakeLoewOP•12/6/24, 7:48 PM

I think a custom signup action will suit my needs! I've been working on it!

M

martinsos•12/7/24, 3:09 PM

Awesome, let us know if you need any help!

M

miho•12/9/24, 1:25 PM

A custom action is the most powerful solution - it's custom, you can do what ever you want.

If you want to maybe avoid that - you could in theory try using auth hooks and set the

isEmailVerified

isEmailVerified

isEmailVerified

isEmailVerified field to

true

true

so the login will automatically. But ... I haven't tested this second idea personally, let me know how you solve it

J

JakeLoewOP•12/9/24, 6:32 PM

Yes, I think it's going to look something like this:

- Our invitation email contains a link with `?token=<some-jwt>`. `Invitation` model has a property `token`.
- `/signup` page checks the url for `?token=`. The token is sent to the custom signup action along with their credentials.
- The custom signup action queries for an `Invitation` with the signup email, and checks that the `token` matches the one sent and is not expired. If it's all good, signup the user with `isEmailVerified:true`. Users without the token will go through the normal email verification flow.

- Our invitation email contains a link with `?token=<some-jwt>`. `Invitation` model has a property `token`.
- `/signup` page checks the url for `?token=`. The token is sent to the custom signup action along with their credentials.
- The custom signup action queries for an `Invitation` with the signup email, and checks that the `token` matches the one sent and is not expired. If it's all good, signup the user with `isEmailVerified:true`. Users without the token will go through the normal email verification flow.

- Our invitation email contains a link with `?token=<some-jwt>`. `Invitation` model has a property `token`.
- `/signup` page checks the url for `?token=`. The token is sent to the custom signup action along with their credentials.
- The custom signup action queries for an `Invitation` with the signup email, and checks that the `token` matches the one sent and is not expired. If it's all good, signup the user with `isEmailVerified:true`. Users without the token will go through the normal email verification flow.

- Our invitation email contains a link with `?token=<some-jwt>`. `Invitation` model has a property `token`.
- `/signup` page checks the url for `?token=`. The token is sent to the custom signup action along with their credentials.
- The custom signup action queries for an `Invitation` with the signup email, and checks that the `token` matches the one sent and is not expired. If it's all good, signup the user with `isEmailVerified:true`. Users without the token will go through the normal email verification flow.

I can see that wasp uses

oslo/jwt

oslo/jwt

oslo/jwt

oslo/jwt for do this under the hood, but I'm hesitant to import

oslo/jwt

oslo/jwt

oslo/jwt

oslo/jwt into my own code because it doesn't seem to be exposed by wasp intentionally. Do you think it's okay to use

oslo/jwt

oslo/jwt

oslo/jwt

oslo/jwt to create and validate jwts in my own code?

P.S. Thank you guys for the support on all these questions! It's super helpful.

M

MEE6•12/9/24, 6:32 PM

Wohooo @JakeLoew, you just became a Waspeteer level 5!

M

miho•12/10/24, 9:34 AM

@JakeLoew I'd just install

oslo/jwt

oslo/jwt

oslo/jwt

oslo/jwt in your

package.json

package.json

just to make sure you have it even if we stop using it and it doesn't hurt if you also have it listed a dep.

The flow you suggested sounds like it should work, you create the user with an already verified email

J

JakeLoewOP•12/10/24, 4:11 PM

Thank you!

Skip email verification for users invited via email.

Similar Threads

Similar Threads

Similar Threads