[MGNLUI-248] The user password is handled incorrectly Created: 28/Nov/12  Updated: 11/Feb/13  Resolved: 30/Nov/12

Status: Closed
Project: Magnolia UI
Component/s: security app
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Critical
Reporter: Jozef Chocholacek Assignee: Federico Grilli
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

When editing an existing user, the password field is pre-filled with the hash of the existing password, which causes this hash to be hashed again on the save, and thus disallowing the user to log in.



 Comments   
Comment by Jozef Chocholacek [ 28/Nov/12 ]

IMHO the working style of the old UI should be adapted: when editing the user, leave the password fields blank, and if they are still blank on save, don't change the saved value.

Comment by Andreas Weder [ 30/Nov/12 ]

I would advice against showing an empty field. We should show that something is there to suggest that a password has actually been set. If the password field remains empty, even if a password has actually been set, and you save a change you've made e.g. to the first name of a user, are you then also setting an empty password? What if you actually wanted to save an empty password?

If this is a problem, there are various ways we can deal with that (e.g. only show a field with stars instead of an input field with stars and have an additional button "change password" next to it).

Comment by Federico Grilli [ 30/Nov/12 ]

I actually chose to display the password field filled because it was technically easier for me to solve the problem As to saving an empty password, I guess this should not be allowed even though we should provide an admin with the ability to set at least a simple password strategy, something like minLength (where this can't be, say, less than 4 chars anyway) and maxLength. I'll add a ticket for that but that will be done in a later sprint I guess.

Comment by Eric Hechinger [ 30/Nov/12 ]

Add a property in the password field definition allowing to deactivate encoding.
Doing so, the saveUserAction will get a clear password and be able to use MgnlUserManager to create a new user handle groups....

Generated at Mon Feb 12 08:35:02 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.