From a800f0d74e95dbc96d27da1af2dcb7452c20bc5c Mon Sep 17 00:00:00 2001 From: Hermes Date: Mon, 13 Jul 2026 16:42:47 -0700 Subject: [PATCH] DC-047: clarify email-only is the identity (no username field) Sami confirmed: the user's email IS their identity. No separate username field at any point. One field, one identifier, no display-name collection on first login. Updated DC-047 ticket to lock this in. --- BACKLOG.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/BACKLOG.md b/BACKLOG.md index cf21e81..c75edb2 100644 --- a/BACKLOG.md +++ b/BACKLOG.md @@ -264,8 +264,8 @@ Tickets DC-033 through DC-041 were added after the DNS2 v1.14.4 / v1.14.8 / 0.0. ### DC-047: EmailMagicLinkProvider — email-only login via nodemailer - **status:** todo - **owner:** unclaimed -- **details:** Second AuthProvider implementation, sitting alongside TOTP. Flow: user enters email at `/login`, server generates a single-use token (32 random bytes, base64url), stores it in `data/email-tokens.json` with 15-min TTL, sends an email via the existing nodemailer connection in `src/managers/notification-manager.js:290` (reuse the same SMTP config — `providers.email.host/port/username/password/from`). Email body contains a link like `https://dashcaddy.example.com/auth/verify?token=abc123`. Click → server validates token (exists, not expired, not already used) → marks used → creates session cookie → redirect to dashboard. On subsequent visits, session cookie is the credential. Rate-limit the request-link endpoint to 5 per email per hour to prevent email-bombing. Tokens stored as SHA-256 hashes in the JSON store so a read-only compromise can't be used to forge links. Effort: ~3 hrs. Risk: medium (depends on SMTP creds being configured; if not, fall back to console-logging the link in dev mode). -- **impact:** Public product readiness. Zero-password login. Reuses existing nodemailer config — no new dependency, no new credential surface. Works with any SMTP server Sami already uses (he mentioned using the SMTP server his website runs). +- **details:** Second AuthProvider implementation, sitting alongside TOTP. **Email IS the identity — no separate username field at any point.** Flow: user enters email at `/login`, server generates a single-use token (32 random bytes, base64url), stores it in `data/email-tokens.json` with 15-min TTL, sends an email via the existing nodemailer connection in `src/managers/notification-manager.js:290` (reuse the same SMTP config — `providers.email.host/port/username/password/from`). Email body contains a link like `https://dashcaddy.example.com/auth/verify?token=abc123`. Click → server validates token (exists, not expired, not already used) → marks used → creates session cookie → redirect to dashboard. On subsequent visits, session cookie is the credential. Rate-limit the request-link endpoint to 5 per email per hour to prevent email-bombing. Tokens stored as SHA-256 hashes in the JSON store so a read-only compromise can't be used to forge links. Effort: ~3 hrs. Risk: medium (depends on SMTP creds being configured; if not, fall back to console-logging the link in dev mode). +- **impact:** Public product readiness. Zero-password login. No username/email split — one field, one identifier. Reuses existing nodemailer config — no new dependency, no new credential surface. Works with any SMTP server Sami already uses (he mentioned using the SMTP server his website runs). - **prerequisite:** DC-046 (the interface to implement against). ### DC-048: Multi-user bootstrap + admin invites