Closed
Bug 390802
Opened 17 years ago
Closed 11 years ago
In the "Name and Password" panel of userprefs.cgi, leaving the "Password" field empty throws an error
Categories
(Bugzilla :: User Accounts, defect)
Tracking
()
RESOLVED
FIXED
Bugzilla 3.6
People
(Reporter: LpSolit, Assigned: LpSolit)
References
Details
(Whiteboard: [fixed by blocker])
Attachments
(2 files)
837 bytes,
patch
|
Details | Diff | Splinter Review | |
2.09 KB,
patch
|
timello
:
review-
|
Details | Diff | Splinter Review |
The old password doesn't need to be given to change the real name only (as it's a safe change which can easily be reverted if desired), but Bugzilla->login complains if this field is left empty, because Bugzilla::Auth::Login::CGI thinks the password is "", which is obviously not the correct one. So we have to delete Bugzilla_password completely (i.e. undef) so that Bugzilla->login looks at the login cookie instead and throws an error only if credentials checks really fail.
Attachment #275118 -
Flags: review?(mkanat)
Comment 1•17 years ago
|
||
I kinda thought this was expected behaviour. After all, the page says "Please enter your existing password to confirm account changes".
Assignee | ||
Comment 2•17 years ago
|
||
No, the code updating the real name is intentionally left outside any check. Only changing your password or your email address requires explicitly checks.
Comment 3•17 years ago
|
||
Comment on attachment 275118 [details] [diff] [review]
patch, v1
Before I give this r+, I think we should audit userprefs.cgi to make sure that this won't introduce any security holes.
Assignee | ||
Comment 4•17 years ago
|
||
Comment on attachment 275118 [details] [diff] [review]
patch, v1
Talking about this with mkanat on IRC, we decided it was better to request the password for *all* changes, including the real name. This way, no risk to bypass checks. I will update my patch accordingly.
Attachment #275118 -
Flags: review?(mkanat)
Assignee | ||
Updated•17 years ago
|
Target Milestone: Bugzilla 3.0 → Bugzilla 3.2
Assignee | ||
Updated•17 years ago
|
Target Milestone: Bugzilla 3.2 → Bugzilla 4.0
Assignee | ||
Updated•14 years ago
|
Assignee: LpSolit → user-accounts
Assignee | ||
Updated•13 years ago
|
Status: ASSIGNED → NEW
Assignee | ||
Comment 5•12 years ago
|
||
We are going to branch for Bugzilla 4.4 next week and this bug is either too invasive to be accepted for 4.4 at this point or shows no recent activity. The target milestone is reset and will be set again *only* when a patch is attached and approved.
I ask the assignee to reassign the bug to the default assignee if you don't plan to work on this bug in the near future, to make it clearer which bugs should be fixed by someone else.
Target Milestone: Bugzilla 4.4 → ---
Comment 7•12 years ago
|
||
Comment on attachment 690949 [details] [diff] [review]
Patch-v1
The change looks trivial. It applies cleanly and it passes in all tests.
Attachment #690949 -
Flags: review?(LpSolit) → review+
Updated•12 years ago
|
Flags: approval?
Assignee | ||
Comment 8•12 years ago
|
||
(In reply to Tiago Mello [:timello] from comment #7)
> The change looks trivial.
I don't think changes are trivial. Did you test with login methods which do not use passwords?
Comment 9•12 years ago
|
||
Comment on attachment 690949 [details] [diff] [review]
Patch-v1
The patch does not work when the password is not needed. For instance when user_info_class is set to 'Env'. It should also check if the login method requires a password (requires_verification constant, possibly).
Attachment #690949 -
Flags: review+ → review-
Updated•12 years ago
|
Flags: approval?
Assignee | ||
Comment 10•11 years ago
|
||
Fixed by bug 553693. No other action required.
Assignee: user-accounts → LpSolit
Severity: normal → minor
Status: NEW → RESOLVED
Closed: 11 years ago
Depends on: 553693
Resolution: --- → FIXED
Whiteboard: [fixed by blocker]
Target Milestone: --- → Bugzilla 3.6
You need to log in
before you can comment on or make changes to this bug.
Description
•