Auth: document the magic-link feature - #49
Conversation
|
Warning This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
This stack of pull requests is managed by Graphite. Learn more about stacking. |
Graphite Automations"Request reviewers once CI passes" took an action on this PR • (07/10/26)2 reviewers were added to this PR based on Henry Chen's automation. |
| email, receives a single-use link, and clicking it establishes a server-side session delivered as an | ||
| httpOnly cookie. | ||
|
|
||
| **Unified signup/login.** Requesting a link never reveals whether an account exists (the response is |
There was a problem hiding this comment.
Seems like the design of this signup flow is pretty focused on avoiding revealing whether or not the email is in the system, which it seems is why we have a silent rate limit?
That's fine to target but seems to lead to bad UX for legitimate users here because users also won't know if they are rate limited. This may actually lead to more attempts.
What if we rate limited (with a 429) for all emails, including non-registered ones? There will still be no distinction between registered and non-registered emails. Does that make sense?
94387bf to
90a5199
Compare
cbf9d36 to
5681d50
Compare
- docs/auth-feature.md mirrors the email-feature doc: shape, login walkthrough, dev log-link trick, and configuration table - AGENTS.md auth row now reflects magic links + Spring Session JDBC Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
5681d50 to
3f5cf30
Compare
90a5199 to
253efb0
Compare
|
2 participants
walkthrough, dev log-link trick, and configuration table
Co-Authored-By: Claude Fable 5 noreply@anthropic.com