Is it the same as #19857 (User Deletion throws error "Password is too weak")?

I can't recreate this one as well. Any @samjf error shows in the log?

@peterhashair I looked at the time and didn't see anything at all sorry 😢 I tried to squeeze any more detail, but unfortunately that is all I got.

@samjf Would be interesting to know if the password confirmation error really only happens when removing a former super user. I would guess that this also happens when removing any other user and maybe even also when saving system or plugin setting.
If you are able to reach out to the reporter maybe ask them if their password works for any other password confirmation overlay and if they are using any special characters in their password.

@samjf Would be interesting to know if the password confirmation error really only happens when removing a former super user. I would guess that this also happens when removing any other user and maybe even also when saving system or plugin setting. If you are able to reach out to the reporter maybe ask them if their password works for any other password confirmation overlay and if they are using any special characters in their password.

I can confirm all type of users are concerned, not only super users.

Are you using any special chars in the password or maybe an additional login plugin like LDAP or SAML?

Are you using any special chars in the password or maybe an additional login plugin like LDAP or SAML?

@sgiehl thanks for your reply, password is obviously strong :) (contains multiple special chars), and not using any saml/oauth connector yet.
What happen is simply password rejected with this message "incorrect password". In the console the request paylod looks like:
token_auth=xxxxx&force_api_session=1&module=API&method=API.getBulkRequest&urls%5B%5D=method%3DUsersManager.deleteUser%26userLogin%3Djohndoe%26passwordConfirmation%3Dzzzzzzzzz&format=json
field passwordConfirmation (zzzzzzzzzz) is urlencoded when posted to matomo.

Hope this helps!

@Olivier-SP would you mind trying to change your password to something without special chars and check if the password prompt for deleting a user then works? That would help us a lot in order to identify the problems origin.

@Olivier-SP would you mind trying to change your password to something without special chars and check if the password prompt for deleting a user then works? That would help us a lot in order to identify the problems origin.

@sgiehl changed my password to something "simple", and worked like a charm :)
Hope this helps to fix it soon !

Edit: but, after being able to remove users, I moved back my password to something secure (my previous password), Matomo told me it was applied, unfortunately after disconnecting/reconnecting my password is not recognized, but kept my previous password.

Edit 2: reset password procedure let me set back a secure password

I was able to reproduce that locally by using a password that contains a &. Can you confirm that your secure password also contained a &?
Seems there is some regression with the sanitizing around the password confirmation. We'll try to have a closer look at that soon.

I was able to reproduce that locally by using a password that contains a &. Can you confirm that your secure password also contained a &? Seems there is some regression with the sanitizing around the password confirmation. We'll try to have a closer look at that soon.

{'-!&(; are the special characters used

Thanks a lot for your time and the coming fix!

Just a note for the developer who's gonna start working on this one: My assumption for the problem is something like this:
It seems we are using the plain password sent in the request for normal login as well as when resetting the password (those forms are still using a quickform). Changing the password and password confirmations are handled using controller / api. where the parameters are sanitized automatically. So changing the password to something containing a html special char might end up in an incorrect password in the database I guess. In addition the password confirmation tries to compare the password, where the parameter is first sanitized and unsanitized before the compare. This might also still contain escaped special chars, where it shouldn't.

We should check the code so we in the end always use the plain parameters for passwords / password confirmations.

We need to move a fix for this to Matomo 5. I tried changing that for Matomo 4, but it's too much effort for a quick fix and the risk of possible other regressions is too high. In addition we already implemented changes to Matomo 5, that will help fixing this a lot easier.

@Olivier-SP If my tests were correct, the char making problems should be &, so not using it in the password should solve the issues. Other characters should work I think.

This issue has been mentioned on Matomo forums. There might be relevant details there:

https://forum.matomo.org/t/badd-username-and-password-when-try-to-upload-a-plugin/51170/2