feat(authenticate): separate login from signup with an explicit intent - #1912
Draft
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Contributor
|
Important Draft PR not reviewedDraft PRs are not automatically reviewed by default.
To automatically review draft PRs, update your CodeRabbit configuration: reviews:
auto_review:
drafts: trueThanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Coverage Report for CI Build 33429107510Coverage increased (+0.4%) to 49.524%Details
Uncovered Changes
Coverage RegressionsNo coverage regressions found. Coverage Stats
💛 - Coveralls |
rohanchkrabrty
marked this pull request as draft
August 31, 2026 10:36
This was referenced Aug 31, 2026
Frontier cannot tell a signup from a login: every strategy ends at getOrCreateUser, which returns the existing user or creates one, so a login with an unknown address silently creates the account. Adds a FlowIntent carried on flow metadata and both gates from the RFC's intent by strategy table. StartFlow is the fast path, rejecting a login with no account or a signup with one before an OTP is sent, for the strategies that know the email that early. User creation is the gate that matters, since every strategy reaches it and OIDC has no email until the callback. The intent also replaces the passkey guess: signup picks the register ceremony, login picks the login ceremony. An unspecified intent keeps today's create-or-get and today's guess, so existing clients and deployments are unaffected. Flow.Metadata is existing JSONB, so no migration. The accessors parse rather than assert, since JSONB does not return the types it was given, and are nil-receiver-safe so the caller without a flow needs no branch. Error mapping at the handlers and all consent work follow separately. Refs docs/rfcs/0002-explicit-consent-at-signup.md Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VW3nysiE4H83VQk6BroMYc
rohanchkrabrty
force-pushed
the
feature/featauthenticate-separate-login-from-signup-with-an-explicit
branch
from
August 31, 2026 19:10
1cb69f7 to
fac50ad
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
StartFlowis the fast path for the strategies that know the address up front, so a rejection lands before anything is mailed;getOrCreateUseris the gate that matters, since every strategy ends there. It now takes the flow, andErrLoginUserNotFound/ErrSignupUserExistsjoin the existing error block.StartFlowused to look the user up to decide between the passkey register and login ceremonies, which meant a passkey login could create an account; the intent now picks the ceremony, and an unspecified intent keeps the old guess.flow.Metadata(existing JSONB, no migration), read back through two nil-receiver-safe accessors that parse rather than assert — JSONB returns[]anyand an RFC 3339 string, not what it was given.applyMailOTPat the other end.