Change a personal address by proving it, and administer accounts

FeatureSecurityService
Ya
4 Septemba 2026, 19:33 UTC
Mwandishi
Kamo
Ahadi ya
545090e

Two surfaces on the USER account, which until now had no server of its own — the account's fields were reachable only through MemberController, an endpoint scoped to "the org in your session", which is the wrong shape for data every membership shares. UserAccountController — the member's own personal address. USERS.EMAIL is the second of the three identifiers sign-in accepts and the address password recovery mails a reset link to. Writing it from a PUT would mean anybody reaching an unattended signed-in browser could re-point recovery at a mailbox they own, walk away, and take the account over later — with the real owner still able to sign in, and therefore with nothing to notice. So the new address is parked, a code and a link go to it, and only an answer moves it. The password is re-demanded although the caller is signed in: a session proves this browser was signed in at some point, the password proves who is at it now, and this is exactly the act where those differ. Only the organization named by security_provider_id may write, and the refusal is here rather than in the UI — it carries that organization's name and its sign-in URL, because a 403 that only says no leaves the member with nowhere to go, and this rule is invisible until it bites. Reads are NOT restricted that way: seeing your own address from another workspace is what makes the refusal comprehensible. The link is deliberately unauthenticated. It goes to a personal mailbox, usually read on a phone that has never signed into the workspace; demanding a session would make it work only for people who did not need it. Possession is the proof — mailed to the claimed address alone, stored as a hash, single-use, expiring in a day, and finite in wrong guesses. The address being left behind is told, although nobody asked for that. It is the only signal that reaches somebody whose session was stolen. UserAdminController — the platform Users tab, guarded by MANAGE_USERS. The one read on the platform that enumerates accounts across every tenant instead of within one organization; the top-level-org precondition arrives with the right, since PlatformRightsResolver returns nothing to a session in a tenant. It deliberately cannot set a password (self-or-god stays where it is; restoring access goes through a reset letter, which proves control of the mailbox rather than bypassing it), cannot delete an account (seven satellite tables and every org it owns — the reversible answer is the synthetic flag, which finally has a UI here), and cannot touch isGod or isSystemUser. The coverage test learns /platform-users, so the next controller added under that prefix must carry a guard rather than inherit one by being overlooked.

Mabadiliko yote

Je, unaona nini kuhusu usafiri?

Kila moja ya hizi updates ardhi katika nafasi yako ya kazi moja kwa moja. Kuanza bure na kuangalia kukua wiki baada ya wiki.

Kuwa Huru MileleMtazamo wa bei