Skip to content

feat(nextjs): confirm cross-device magic links and move to @seamless-auth/nextjs 0.5 - #124

Merged
Bccorb merged 3 commits into
mainfrom
feat/nextjs-magic-link-confirm
Oct 18, 2026
Merged

Bccorb merged 3 commits into
mainfrom
feat/nextjs-magic-link-confirm

Conversation

@Bccorb

@Bccorb Bccorb commented Oct 18, 2026 •

Copy link
Copy Markdown
Contributor

Part of the v0.19 security release (fells-code/seamless-auth-api#385). Merge before fells-code/seamless-auth-api#449: its conformance run builds the Next.js starter from this repo's main and lockfile, and the same-browser magic link case needs the 0.5 adapter.

What

  • The Next.js starter's VerifyMagicLink handles the auth server's 409 confirmation_required: it names the requesting device and time, and offers "Yes, sign in that device" (confirms via client.confirmMagicLink when the SDK has it, otherwise POST /auth/magic-link/verify/{token}/confirm) or "No, this wasn't me" (signs nothing in). Reviewed in the private advisory fork
  • @seamless-auth/nextjs ^0.4.0 to ^0.5.0, which forwards the browser's pre-auth token on verify so a link opened in the requesting browser signs in directly
  • @seamless-auth/react stays on ^0.15.2 (0.15.3): 0.16's authorizedFetch refuses every path when apiHost is empty, which broke the starter's /api/beta-users call in the first conformance run. Tracked in fix(client): authorizedFetch refuses every path when apiHost is empty (same-origin apps) seamless-auth-react#188; the bump follows in chore: move the templates to @seamless-auth/react 0.16 and react-native 0.3 #123 once it is fixed
  • AGENTS.md note; two minor changesets

Checks

  • templates/fullstack/nextjs: npm run check (tsc, eslint, prettier, vitest): 10 files, 61 tests pass; npm run build: pass
  • Root: npm run validate and npm run format:check: pass

Handle the auth server's 409 confirmation_required answer on the verify
page: show the requesting device class and time, approve through
confirmMagicLink (or a POST through /auth on older SDKs), or decline
without side effects.
React 0.16's authorizedFetch refuses a path when apiHost is empty, which
breaks the starter's same-origin calls to its own API.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant