josh/YesChef
1
0
Fork 0
Code Pull Requests Actions Packages Projects Releases Activity

Backlog: email-based admin invites + email confirmation in one flow

Browse Source 
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Josh Rogers
2026-05-08 22:06:03 -05:00
parent fa1d4b4f62
commit 86603b4f4a
1 changed files with 7 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
BACKLOG.md
+7
View File
@@ -20,6 +20,13 @@ Prerequisite for the product catalog and unit catalog work — both rely on a `F
- **JWT refresh tokens.** Today's tokens are signed with HS256 and (per `Program.cs`) likely have no refresh path; they expire and the user gets bounced to login. Add refresh tokens with rotation + revocation list.
- **Account deletion / data export.** GDPR-style request handling. Family-scoped: deleting a user shouldn't delete the family's data, but should redact PII.
- **Rate limiting on `/api/auth/register` and `/api/auth/login`.** Currently unlimited — with multi-family this becomes a real abuse vector.
- **Email-based invites (admin-sent) doubling as email confirmation.** Today the `InviteCode` is a shareable secret an admin distributes out-of-band; new users self-register with it and there's no proof they own a real email address. Build an invite flow where a family admin enters an email, the backend issues a single-use, time-limited invite token and sends a templated email containing a join link. Clicking the link drops the user into a registration form pre-bound to that family + email; on submit, both the invite is consumed and the email is marked confirmed in one step (no second "confirm your email" round-trip needed). Implications:
- New table for invites: `(Id, FamilyId, Email, TokenHash, IssuedByUserId, IssuedAt, ExpiresAt, ConsumedAt, ConsumedByUserId)`. Hash the token (don't store raw) so a DB leak doesn't leak active invites.
- `User` gains an `Email` (unique) and `EmailConfirmedAt` column. Migration backfill: existing users have null email until they (or an admin) attach one.
- SMTP infrastructure shared with the password-reset item above — design both together; same templating, same rate limits, same outbound queue if we add one.
- Admin UI on `/family`: list pending invites, resend, revoke. Pair with the existing role/membership management.
- Keep the old `InviteCode` flow available initially (or as an admin-only "generate shareable code" fallback) so we don't strand families that prefer the link-share workflow. Revisit deprecation once email invites are battle-tested.
- Open question: do we allow registering without an invite at all once email invites land? Recommend yes-for-now (existing `InviteCode` path stays) so this can ship incrementally.
### Real-time conflict resolution
- The deferred SignalR-versioning plan in memory addresses connect-window races. It does **not** address edit conflicts (two family members renaming the same store, unchecking-then-checking the same item simultaneously).