Do SikiandClaude Sonnet 5
8407b45367
CI Pipeline with Test Management / 🧪 Run Tests & Generate Reports (push) Waiting to run
CI Pipeline with Test Management / 🐳 Docker Integration Tests (push) Blocked by required conditions
CI Pipeline with Test Management / 🏗️ Build Docker Image (push) Blocked by required conditions
CI Pipeline with Test Management / 📊 Generate Test Summary (push) Blocked by required conditions
Test Reporting & Gherkin Analysis / 🧪 Run Tests & Generate Reports (push) Waiting to run
Test Reporting & Gherkin Analysis / 📊 Analyze Test Coverage (push) Blocked by required conditions
Test Reporting & Gherkin Analysis / 🔄 Sync with Linear (push) Blocked by required conditions
Test Reporting & Gherkin Analysis / ⚡ Performance Monitoring (push) Blocked by required conditions
Explicit, documented decisions instead of relying on implicit Payload
defaults:
- auth.maxLoginAttempts: 5, lockTime: 10 min — codifies the lockout
policy rather than leaving it as an unstated library default.
- auth.cookies: { secure: NODE_ENV === 'production', sameSite: 'Lax' }
— secure cookies once behind HTTPS (MITHOME-15), harmless over plain
HTTP in local dev.
- access.{create,read,update,delete,unlock}: explicit
requireAuthenticatedUser (== Payload's defaultAccess, Boolean(user)).
Investigated the known open advisory flagged in MITHOME-86
(GHSA-jg8r-5jh2-v2xj — any authenticated user can unlock any other
account) by reading Payload's unlock operation source: the gap only
matters when a less-privileged authenticated identity exists that
needs protecting from a more-privileged one. This project's single
"admin" role model (no role hierarchy — MITHOME-85 epic decision)
has no such identity, so the default is accepted as-is, with the
reasoning and a MITHOME-46 (central IDM/SSO) revisit trigger written
into the code comment rather than left implicit.
- Added an optional `name` field for a nicer admin identity than a
bare email (audit trail, header display).
Verified live: existing dev@mozdit.hu user unaffected (name column
shows "<No Name>", backward compatible). Reproduced the lockout for
real — 5 wrong POST /api/users/login attempts, 6th attempt with the
*correct* password still rejected ("locked due to too many failed
login attempts"), unlocked via Local API (overrideAccess), then the
correct password logged in successfully. build/lint/tsc/test (58
passed) all clean.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>