[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 |
| Comment by Philipp Bracher [ 09/Oct/08 ] |
|
Is a blocker. |
| Comment by Jan Haderka [ 10/Oct/08 ] |
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. |
| 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. trunk - r18937, r18938, 3.6 branch - r18939. |