53 lines
3 KiB
YAML
53 lines
3 KiB
YAML
|
decisions_log:
|
||
|
|
- question: What is the password-reset/forgot-password flow (self-service email link, admin-reset only, or both)?
|
||
|
|
decision: >
|
||
|
|
A logged-in user changes their own password from their Profile page (see
|
||
|
|
"Password Reset" note above); this handles a known/current password change.
|
||
|
|
rationale: >
|
||
|
|
Reuses the Profile Management capability already planned for backend users
|
||
|
|
instead of building a separate flow for a password change.
|
||
|
|
- question: >
|
||
|
|
Is there a login rate-limiting/lockout policy (e.g. temporary lockout after N
|
||
|
|
failed attempts) to complement 2FA?
|
||
|
|
decision: >
|
||
|
|
Yes — a temporary 2-hour lockout after 3 failed login attempts, which an Admin
|
||
|
|
can manually override/unlock (see "Login Lockout Policy" note above).
|
||
|
|
rationale: >
|
||
|
|
Slows down brute-force login attempts while giving the Admin an escape hatch
|
||
|
|
for a legitimately locked-out user.
|
||
|
|
- question: >
|
||
|
|
Should the public-facing User (commenter) role require email verification before
|
||
|
|
their comments are accepted/shown?
|
||
|
|
decision: >
|
||
|
|
Email verification is required after account creation, but is not a
|
||
|
|
precondition for submitting a comment (see "Email Verification" note above).
|
||
|
|
rationale: >
|
||
|
|
Confirms the commenter's email address without adding friction/delay to the
|
||
|
|
act of leaving a comment itself.
|
||
|
|
- question: Can a site have more than 1 Admin account?
|
||
|
|
decision: >
|
||
|
|
Yes — a site can have more than one Admin account (see "Multiple Admin
|
||
|
|
Accounts" note above).
|
||
|
|
rationale: >
|
||
|
|
Matches the intended usage model where the developer holds an Admin account on
|
||
|
|
every CMS instance alongside a separate Admin account created per client.
|
||
|
|
- question: >
|
||
|
|
The Profile-page password change requires being logged in already, so it
|
||
|
|
doesn't cover a user who has forgotten their password and is locked out. Is a
|
||
|
|
true "forgot password" recovery path needed (e.g. a self-service emailed
|
||
|
|
reset link) for that case, or is recovery always Admin-assisted (an Admin
|
||
|
|
manually resets/unlocks the account)?
|
||
|
|
decision: >
|
||
|
|
Yes, a self-service Forgot Password recovery path is needed. It works via an
|
||
|
|
emailed, tokenized reset link that is valid for 1 hour; the user follows the
|
||
|
|
link to set a new password directly. Successfully completing a reset also
|
||
|
|
clears/unlocks any active Login Lockout on that account (see "Login Lockout
|
||
|
|
Policy" above), since proving ownership of the account's email is treated as
|
||
|
|
sufficient to lift the lockout.
|
||
|
|
rationale: >
|
||
|
|
Covers the case the logged-in Profile-page password change can't handle (a
|
||
|
|
forgotten password while locked out), without always requiring Admin
|
||
|
|
involvement. A 1-hour token expiration limits the exposure window for a
|
||
|
|
leaked/intercepted reset link, and clearing the lockout on successful reset
|
||
|
|
avoids forcing a legitimate user to wait out the full 2-hour lockout after
|
||
|
|
already proving account ownership via email.
|