swarmctl: add user reset-password
authelia's file backend has no self-service reset (no SMTP notifier), so the only way a human account got a new password after the old one was forgotten was hand-editing users.yml as root. `user add` already hashes a password into the file; this verb does the same for an existing user instead of refusing on the name. Mirrors `user add`'s UX exactly: no password flag, authelia generates and hashes it (never crosses argv), and it's printed once and never stored. Refuses on an unknown user before ever invoking authelia. Same publish path as add/update, so the same atomic write and no-restart (authelia watches the file) behaviour apply. Split the digest-replacement into users::reset_password so it's testable without a command line or a running authelia, same pattern as apply_update.
This commit is contained in:
parent
ccb5bd3b38
commit
69ae23f801
4 changed files with 151 additions and 1 deletions
|
|
@ -91,7 +91,19 @@ Two behaviours worth knowing before you rely on them:
|
|||
|
||||
Passwords are deliberately out of scope here: regenerating a credential
|
||||
is a different intent from editing an attribute, and folding them means
|
||||
an attribute edit can invalidate a login by accident.
|
||||
an attribute edit can invalidate a login by accident. Resetting one is a
|
||||
separate verb, `user reset-password`, which generates and hashes a new
|
||||
password the same way `user add` does and refuses on an unknown user:
|
||||
|
||||
```console
|
||||
# swarmctl user reset-password mara
|
||||
reset password for mara in /var/lib/authelia-swarm/users.yml
|
||||
password: <generated>
|
||||
this password is stored nowhere — record it now
|
||||
```
|
||||
|
||||
Authelia's file store has no SMTP notifier, so this is the only way a
|
||||
human account gets a new password once an operator forgets the old one.
|
||||
|
||||
## What secrets exist, and where each one lives
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue