[MAGNOLIA-2416] Changing users password is possible without filling in the confirmation field. Created: 08/Oct/08  Updated: 23/Jan/13  Resolved: 10/Oct/08

Status: Closed
Project: Magnolia
Component/s: admininterface
Affects Version/s: 3.0.5, 3.5.9, 3.6.3
Fix Version/s: 4.0

Type: Bug Priority: Blocker
Reporter: Bert Leunis Assignee: Jan Haderka
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 changing the password for superuser, we did not fill in the second field. It stayed blank, but we could still save the userinfo. So when you make an error in typing the password, you could lose the entry to magnolia as superuser. Doesn't seem to be very handy.



 Comments   
Comment by Magnolia International [ 08/Oct/08 ]

Ouch, could indeed just reproduce this on http://demoauthor.magnolia.info
This looks like a regression, I'm pretty sure it wasn't the case "before".

Comment by Philipp Bracher [ 09/Oct/08 ]

Is a blocker.

Comment by Jan Haderka [ 10/Oct/08 ]

This looks like a regression, I'm pretty sure it wasn't the case "before".

I would not be so sure. If you put in wrong password in second field the validation kicks in. It is not enabled on the first field because of cases when you are not changing the password at all.
And I just reproduced this with 3.0.5

Comment by Magnolia International [ 10/Oct/08 ]

(edited to only leave in the latest release of each branch - issue navigator otherwise becomes stupidly unreadable)

Comment by Jan Haderka [ 10/Oct/08 ]

The obvious solution to the issue is to fill value always in both fields. When I look in code I could see that this was done once before, but is commented out now without explanation ... and have been commented out ever since first revision of DialogPassword (r206) in svn.

Comment by Jan Haderka [ 10/Oct/08 ]

Changing client side javascript posed some undesired side effects (circular validation) as well as forcing both fields to be filled all the time. Solved by implementing server side validation for DialogPassword. Seems to be safer way to handle things like changing password since its behaviour can be easily tested and can't be bypassed by the client.
Added tests for the validation.

trunk - r18937, r18938, 3.6 branch - r18939.

Generated at Mon Feb 12 03:36:30 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.