github-starred/better-auth
2
0
Fork 0
mirror of https://github.com/better-auth/better-auth.git synced 2026-05-24 16:11:53 -05:00
Code Issues 2.5k Packages Projects Releases 112 Wiki Activity

[PR #2632] [CLOSED] Fix: Set pending 2FA cookie during setup to prevent INVALID_TWO_FACTOR_COOKIE error (#2631) #21313

New Issue
Closed
opened 2026-04-15 20:16:31 -05:00 by GiteaMirror · 0 comments
GiteaMirror commented 2026-04-15 20:16:31 -05:00
Owner
Copy Link

📋 Pull Request Information

Original PR: https://github.com/better-auth/better-auth/pull/2632
Author: @obendev
Created: 5/12/2025
Status: ❌ Closed

Base: main ← Head: fix/2631-2fa-enable-cookie

📝 Commits (1)

  • f80aa41 fix(two-factor): Set pending cookie on 2FA enable (#2631)

📊 Changes

1 file changed (+59 additions, -17 deletions)

View changed files

📝 packages/better-auth/src/plugins/two-factor/index.ts (+59 -17)

📄 Description

Closes #2631

Problem:

When setting up 2FA (TOTP) using the twoFactor plugin with the default skipVerificationOnEnable: false setting, submitting the TOTP code via /two-factor/verify-totp incorrectly resulted in an INVALID_TWO_FACTOR_COOKIE error. This occurred even when testing with an intentionally incorrect TOTP code, where an INVALID_CODE error was expected.

Root Cause:

The analysis traced this back to the /two-factor/enable endpoint handler in packages/better-auth/src/plugins/two-factor/index.ts. When skipVerificationOnEnable is false, this handler successfully generated the totpURI but failed to set the necessary TWO_FACTOR_COOKIE_NAME. This cookie is required by the verifyTwoFactor helper (used by /two-factor/verify-totp) to link the verification attempt back to the correct user and pending state. Without the cookie, the verification flow failed before the submitted TOTP code could actually be validated.

Solution:

This PR modifies the enableTwoFactor handler to address this gap. When skipVerificationOnEnable is false, the handler now mirrors the logic used in the sign-in after hook for establishing a pending 2FA state:

  1. It creates a unique verification identifier.
  2. It stores this identifier in the verification database table, linked to the userId and including an expiry time (consistent with the sign-in hook: options?.otpOptions?.period || 60 * 5).
  3. It sets the signed TWO_FACTOR_COOKIE_NAME on the client response, containing this identifier.

Outcome:

With this change, the /two-factor/verify-totp endpoint can now correctly find the pending verification context using the cookie. It can then proceed to validate the submitted TOTP code against the stored secret, returning INVALID_CODE for incorrect codes or successfully enabling 2FA for correct codes.

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/better-auth/better-auth/pull/2632 **Author:** [@obendev](https://github.com/obendev) **Created:** 5/12/2025 **Status:** ❌ Closed **Base:** `main` ← **Head:** `fix/2631-2fa-enable-cookie` --- ### 📝 Commits (1) - [`f80aa41`](https://github.com/better-auth/better-auth/commit/f80aa41449ed0aa016c6e426c4f608cdbde55dc6) fix(two-factor): Set pending cookie on 2FA enable (#2631) ### 📊 Changes **1 file changed** (+59 additions, -17 deletions) <details> <summary>View changed files</summary> 📝 `packages/better-auth/src/plugins/two-factor/index.ts` (+59 -17) </details> ### 📄 Description Closes #2631 **Problem:** When setting up 2FA (TOTP) using the `twoFactor` plugin with the default `skipVerificationOnEnable: false` setting, submitting the TOTP code via `/two-factor/verify-totp` incorrectly resulted in an `INVALID_TWO_FACTOR_COOKIE` error. This occurred even when testing with an intentionally incorrect TOTP code, where an `INVALID_CODE` error was expected. **Root Cause:** The analysis traced this back to the `/two-factor/enable` endpoint handler in `packages/better-auth/src/plugins/two-factor/index.ts`. When `skipVerificationOnEnable` is `false`, this handler successfully generated the `totpURI` but failed to set the necessary `TWO_FACTOR_COOKIE_NAME`. This cookie is required by the `verifyTwoFactor` helper (used by `/two-factor/verify-totp`) to link the verification attempt back to the correct user and pending state. Without the cookie, the verification flow failed before the submitted TOTP code could actually be validated. **Solution:** This PR modifies the `enableTwoFactor` handler to address this gap. When `skipVerificationOnEnable` is `false`, the handler now mirrors the logic used in the sign-in `after` hook for establishing a pending 2FA state: 1. It creates a unique verification `identifier`. 2. It stores this identifier in the `verification` database table, linked to the `userId` and including an expiry time (consistent with the sign-in hook: `options?.otpOptions?.period || 60 * 5`). 3. It sets the signed `TWO_FACTOR_COOKIE_NAME` on the client response, containing this `identifier`. **Outcome:** With this change, the `/two-factor/verify-totp` endpoint can now correctly find the pending verification context using the cookie. It can then proceed to validate the submitted TOTP code against the stored secret, returning `INVALID_CODE` for incorrect codes or successfully enabling 2FA for correct codes. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
GiteaMirror added the pull-request label 2026-04-15 20:16:31 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
adapter
astro
awaiting external contributor
blocked
breaking
breaking change
bug
c-devops
core
credentials
database
dependencies
devops
devtools
docs
documentation
duplicate
elysia
enhancement
enterprise
expo
express
fastify
good first issue
help wanted
hono
identity
infra
integration
invalid
javascript
locked
maintenance
need-more-information
needs: info
needs: repro
nextjs
nuxt
oauth
organization
P0
payments
perf
platform
plugin
pull-request
Mirrored from GitHub Pull Request
 question
ready
regression
remix
security
social-provider
solid
stale
svelte
tanstack-start
tracking
version-bump
vue
wontfix
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/better-auth#21313
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?