fixed client server password reset

This commit is contained in:
Priec
2026-08-11 11:57:36 +02:00
parent 71106a04cb
commit 5602140d05
2 changed files with 3 additions and 3 deletions

View File

@@ -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.