Aman-Mittal opened a new issue, #752: URL: https://github.com/apache/fineract-backoffice-ui/issues/752
### Summary When Fineract rejects a password on **Create User** for not meeting the password policy, the error toast prints the submitted password in clear text, followed by the policy regex. A password typed into a masked field ends up readable on screen. ### Environment - App: https://aman-mittal.github.io/fineract-backoffice-ui (deployed `main`), route `/security/users/create` - Backend: `sandbox.mifos.community`, tenant `default`, default password policy - Role: superuser (`mifos`) - Chrome 1440×900, 2026-10-16 ### Preconditions None beyond `CREATE_USER`. ### Steps to reproduce 1. **Security → Users → Create User**. 2. Fill in every field. In both password fields, enter a value that breaks the policy only by having two identical consecutive characters (for example, anything containing `ss`). 3. Click **Save**. ### Expected behavior A message describing the rule that failed ("Password must be 12 to 50 characters… with no consecutive repeating characters"), shown next to the field, **without the submitted value**. ### Actual behavior `POST /users` → **400** `validation.msg.user.password.does.not.match.regexp`, and the toast reads: ``` Validation errors exist. • [password] Password must be 12 to 50 characters long, containing at least one uppercase letter, one lowercase letter, one numeric digit, and one special character, with no spaces or consecutive repeating characters (<the submitted password in clear text>, ^(?!.*(.)\1)(?!.*\s)(?=.*\d)(?=.*[a-z])(… ``` The text in parentheses is the platform's `defaultUserMessageArgs` / `value`, which the toast formatter appends verbatim. ### Evidence Observed in the toast in a live session. The submitted value was a throwaway test string, deliberately left out of this issue. ### Impact - The password field is masked so the value isn't visible over the operator's shoulder, on a shared screen, or in a screenshot attached to a support ticket. This toast undoes that. - The same formatter probably handles every validation error, so any other sensitive field the platform echoes back (PINs, secrets in config forms) would leak the same way. - The raw regex is meaningless to an operator. ### Suggested investigation Find the shared error-to-toast formatter (likely the `errorInterceptor` or the toast service) that renders `errors[].defaultUserMessage` plus its args. Suppress args for fields whose `parameterName` is in a sensitive list (`password`, `repeatPassword`, anything `*secret*`, `*pin*`), or stop appending raw args altogether and map known codes to translated messages. ### Verification status Reproduced once in a live session. Other sensitive fields were not tested. ### Related endpoints `POST /users` (and any endpoint whose validation errors carry the submitted value) ### Acceptance criteria - Submitting a policy-violating password shows the rule, with no part of the submitted value in the toast, the inline message or the console. - A unit test on the formatter: an error with `parameterName: "password"` and a value in its args renders without that value. ### Related issues None found. -- 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]
