fixed client server password reset
This commit is contained in:
@@ -5,8 +5,8 @@ Scope: TUI client (`client/`) vs server (`server/`) against the shared API (`com
|
||||
|
||||
## Auth
|
||||
|
||||
**1. One-time password bootstrap is missing in the client.**
|
||||
The server added passwordless bootstrap accounts — a fresh DB ships `superadmin`/`admin` with no password — and the `SetInitialPassword` RPC (`common/proto/auth.proto`, commits 83899c0, 4d6c189, a5c8e08). The client has zero references to it: on a fresh install you cannot claim the admin account from the TUI client (web or a manual call is required).
|
||||
**1. Change password is in the client; bootstrap now flows through it (verified, no drift).**
|
||||
Commit 71106a0 "pws reset" replaced `SetInitialPassword` with two RPCs (`common/proto/auth.proto`): `ChangePassword` — the authenticated user changes their own password after the current one is verified, and an empty current password is accepted for freshly seeded `admin`/`superadmin` accounts — and `ResetUserPassword`, which lets a higher-ranked user reset a lower-ranked user's password (`server/src/auth/handlers/password.rs`). The TUI client now implements `ChangePassword` (page `client/src/pages/change_password`, RPC `client/src/services/auth.rs`): log in with an empty password on a fresh install, then change it. `ResetUserPassword` stays server-side administration tooling, consistent with item 5.
|
||||
|
||||
**2. Self-registration is aligned (verified, no drift).**
|
||||
The server ignores any requested role and always creates `guest` (`server/src/auth/handlers/register.rs`); the client sends no role (`client/src/services/auth.rs`) and shows the returned role.
|
||||
|
||||
Reference in New Issue
Block a user