Aman-Mittal opened a new pull request, #817:
URL: https://github.com/apache/fineract-backoffice-ui/pull/817
Three issues on the Security screens, all measured against a running
Fineract: #752, #753 and #755.
## 1. A rejected password was printed in the toast (#752)
Fineract returns the value it rejected in the error's `args`, and the toast
formatter appends them. For a password that is a disclosure — measured, `POST
/users` with a password the policy refuses answers:
```json
{ "parameterName": "password",
"userMessageGlobalisationCode":
"validation.msg.user.password.does.not.match.regexp",
"args": [ { "value": "<the submitted password>" }, { "value":
"^(?!.*(.)\\1)…" } ] }
```
and the `repeatPassword` entry beside it carries **both** values. The field
is masked precisely so the value is not readable on screen, over a shoulder, in
a screenshot or in a support ticket.
Args are now dropped for any parameter whose name contains `password`,
`secret`, `pin`, `token`, `credential` or `otp` — a substring test, so
`repeatPassword` and `clientSecret` are covered without enumerating spellings.
Dropped entirely rather than filtered for the value: the only other thing in
them is the policy regex, which no operator can act on. The rules still reach
the user, and a non-sensitive parameter keeps its args — a refused amount or
date is what that detail is for.
## 2. The password is now checked before it is sent (#753)
Create User validated both password fields for presence only: with different
values in them Save stayed enabled and the only feedback was the 400 above.
The rules are the tenant's own. `GET /passwordpreferences` answers the
active policy and `/passwordpreferences/template` all three (`simple`,
`secure`, `strong`), each with the platform's own description — shown as the
field's helper text rather than restated. What that endpoint does *not* answer
is the regex it enforces: that appears only in the `args` of a rejected
password, which carry the password with it, so
`core/security/password-policy.ts` mirrors the rules by `key`. The fallback
honours the one obligation that creates — an unrecognised key gets the loosest
rules, so a policy this code has not heard of cannot refuse a password the
platform would have accepted.
The form names the rules a password still fails (`repeat no character twice
in a row` for one refused on its `ss` alone, which the platform's message never
says), reports a mismatch under the confirmation field, and holds Save until
both are right. The profile screen's change-password form shares the same rules
through the same adapter operation, so the two cannot drift.
The password pair also moved into signals: `[(ngModel)]="user().password"`
mutates the object a signal holds without notifying it, so nothing derived from
it would recompute — the trap that emptied the floating-rate editor in #815.
## 3. Access can be withdrawn (#755)
Roles and Users offered create and edit only, so cutting a leaver's access
meant editing their roles down to nothing, and a role created by mistake stayed
in every picker.
- a role can be **disabled, re-enabled and deleted**. `GET /roles` has
always carried `disabled` — the stock `Self Service User` role answers `true` —
and the list now shows it as a status and acts on it. `GET /users/template`
already filters disabled roles out of the options for a new user, so switching
one off is enough to stop it being assigned.
- a user can be **deleted**, the only withdrawal the platform offers for an
account. Never the signed-in one: the platform allows that, and it would lock
the administrator out of the instance.
All four actions are gated on `DISABLE_ROLE`, `ENABLE_ROLE`, `DELETE_ROLE`
and `DELETE_USER`, and confirmed first (destructively for the deletes). `DELETE
/roles/{id}` while a user holds the role answers 403
`error.msg.role.associated.with.users.deleted`, and that reaches the user as
"Role with identifier 34 associated with users" — `errorInterceptor` already
reports a domain-rule 403 in the platform's own words.
## Checks
- unit tests: 312 files, 2536 tests green. New specs for the policy rules
(11 cases), the two new adapter operations each, the roles list's lifecycle, a
users list spec that did not exist, the Create User password gate, and the
profile form's shared rules. The password-echo test fails without its fix.
- driven in the browser against a running Fineract: the policy hint reads
the tenant's description; typing `passsword1A!x` reports *This password must
still: repeat no character twice in a row* and nothing else; a mismatch shows
under the confirmation and Save is disabled; the probe role went ACTIVE →
DISABLED → ACTIVE and was then deleted; a probe user was deleted; the signed-in
account offers no Delete; and deleting an assigned role was refused with the
platform's own reason.
- lint 0 errors, `api:surface` re-recorded for the three new operations,
`i18n:check`, `format:check`, `check:permission-codes`, `check:template-text`,
`check:a11y-names`, `check:ui-primitives`, `check:icons`,
`check:route-permissions` all clean.
## Note on #492
Closed by earlier work, not by this PR: `/profile` already has a Change
Password form. What it was missing is the rule-level validation above, which it
now shares with Create User.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
