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

Auth/nextjs: The onEmailVerify fails with no pkce verifier when resending the verification email. #906

Closed
MiroslavPetrik opened this issue Mar 13, 2024 · 1 comment · Fixed by #907
Labels

Comments

@MiroslavPetrik
Copy link
Contributor

MiroslavPetrik commented Mar 13, 2024

Describe the bug
The emailpassword/verify route handler expects pkce verifier

but the emailPasswordResendVerificationEmail action never sets it.

Expected behavior
the onEmailVerify should succeed with the emailPasswordResendVerificationEmail server action.

Versions (please complete the following information):

  • OS: W11
  • EdgeDB version (e.g. 2.0): 4.5+28216a1
  • EdgeDB CLI version (e.g. 2.0): 4.1.0+127aeb9
    "@edgedb/auth-nextjs": "0.2.0-beta.0"

Additional context
A similar action - sendPasswordResetEmail is setting the verifier, so the fix should be analogical

const { verifier } = await (

@scotttrinh scotttrinh added the bug label Mar 13, 2024
@scotttrinh
Copy link
Collaborator

Yeah, this is interesting. This seems to be an issue that we overlooked when extending the verification flow to allow just the email. We should've required email and challenge so that we can encode the challenge into the new verification token that is sent since that is what is validated server-side.

So, at the moment, if you send an email-only verification resend request, it just verifies the email and redirects you back to a provided redirect_to, or else returns a 204 No Content response, but the email is now verified and you can now perform a login flow. At the time I added that flow, I didn't consider that everything assumes that verification ends with an actual login.

I believe we have (at least) two options:

  1. Handle email+challenge in the resend flow, and start a new PKCE flow when resending verification emails like in the password reset flow.
  2. Handle the redirect_to and 204 No Content flow in a way that requires the user to explicitly log in after verification.

I think it would be useful to handle both of those cases in our auth helper libraries, but starting with the first one is probably the way to go here. I'll get this patched up now!

@scotttrinh scotttrinh linked a pull request Mar 13, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants