Open
Bug 444515
Opened 16 years ago
Updated 2 years ago
"Passwords do not match, please retype" error message while adding device to cacti
Categories
(Toolkit :: Password Manager: Site Compatibility, defect, P3)
Toolkit
Password Manager: Site Compatibility
Tracking
()
NEW
People
(Reporter: e.wolter, Unassigned)
References
(Depends on 1 open bug)
Details
Attachments
(2 files, 1 obsolete file)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 The cacti server is used to monitor network devices. cacti version 0.8.7b; While trying to add a new device to cacti system (link: http://<cacti-server>/cacti/host.php?action=edit&host_template_id=-1&host_status=-1) causes "Passwords do not match, please retype" error after you hit submit. Here is the forum that provided lots of troubleshooting for this problem: http://forums.cacti.net/about24765.html the problem does not show itself if IE is used on the same system connecting to the same server. Reproducible: Always Steps to Reproduce: 1. login to cacti as administrator 2. go to Devices and click on add 3. fill in all the information and click "Create" button. the next screen shows the error message. the FF password manager needs to remember your password for this site in order for the problem to reappear. Actual Results: the same screen shows up with the error message in red. Expected Results: the next screen should show successful addition of the device to the monitoring system
Comment 1•16 years ago
|
||
That's an error from the server, so it doesn't really indicate what, if anything, is happening on the client side (browser). Please attach some debug output per http://wiki.mozilla.org/Firefox:Password_Manager_Debugging when replicating the problem. Also, can you attach the HTML of the form being used?
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → INCOMPLETE
It should be noted that FF2 works fine but I have the exact same problem using FF3. IE also works fine.
the debug output starts from the beginning, when I log into cacti system, username is admin.
Comment 4•16 years ago
|
||
I presume you are not actually trying to enter/change the SNMP password on the page? Are the password fields even visible on the page? It looks like the page is one giant form, and JS selectively hides portions of it (element.style.display = "none"). The password manager ignores the styling, so it's filling in a username and a password into one of the fields. The server sees the full form data (even if the user doesn't), and so is presumably complaining that the two password fields don't match.
Status: RESOLVED → UNCONFIRMED
Resolution: INCOMPLETE → ---
Comment 5•16 years ago
|
||
Assuming the questing in my last comment are true, I think this should fix the problem (else this patch can move to a different bug)... I remember talking about this before somewhere, but can't find it. Guess it never got filed as a bug. Anyway. There's ambiguity when we fill in a 2-password form like: <form> <input name="username"> <input name="pw1" type="password"> <input name="pw2" type="password"> </form> Possible uses for such a form: 1. The first pwfield is for the user's password, and the second pwfield is for the user's PIN (or some other secondary authentication). We want to fill the first field with the one password we store with the login. (The user will have to enter the 2nd auth manually, unsupported). 2. This could be a poorly designed change-password field, without confirmation. We want to fill in the first field, and the user will enter their password in the second field (and pray they don't make a typo!) 3. This could be a properly-designed change-password field, where the user is already known to be logged in (or otherwise has access to change the password), so the current password is not needed and we should ideally not fill in anything. You seem to have case 3 here. Normally this is just a bit of an inconvenience, because we've filled in the old password and the user is going to clear that out and enter their desired new password twice. Unfortunately the page is trying to be clever, and has already filled in your old password twice. [I'm guessing that internally it's always "changes" your password to the same value, or treats old == new as a special case and does nothing.) In other circumstances we might not be able to fix this without breaking other cases (due to the ambiguity noted above), and the page would have to add autocomplete=off as a workaround. But I think we can do the right thing here, because the fields already have a password set -- we just shouldn't clobber them. This is basically what bug 327977 does, for password-only forms. This patch extends that to cover forms that have a username too. [This patch is on top of bug 327977 and bug 400795.] Gavin, does this seem sensible?
Assignee: nobody → dolske
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #329567 -
Flags: review?
Updated•16 years ago
|
Attachment #329567 -
Flags: review? → review?(gavin.sharp)
(In reply to comment #4) > I presume you are not actually trying to enter/change the SNMP password on the > page? Are the password fields even visible on the page? > > It looks like the page is one giant form, and JS selectively hides portions of > it (element.style.display = "none"). The password manager ignores the styling, > so it's filling in a username and a password into one of the fields. The server > sees the full form data (even if the user doesn't), and so is presumably > complaining that the two password fields don't match. > Justin, sorry for the late reply. The form contains credentials that the monitoring system will use when accessing the router/switch. the most of it is done using SNMP. we use SNMP ver2, which uses SNMP community string, BUT, if were to use SNMP ver3 - it requires username/password, as you mentioned are hidden when SNMP v2 is selected. from what you are saying, the FF fills those hidden fields anyway. I hope this helps with your research. Please let me know if I can provide you more information.
(In reply to comment #5) > Created an attachment (id=329567) [details] > Patch v.1 > > Assuming the questing in my last comment are true, I think this should fix the > problem (else this patch can move to a different bug)... > > I remember talking about this before somewhere, but can't find it. Guess it > never got filed as a bug. Anyway. There's ambiguity when we fill in a > 2-password form like: > > <form> > <input name="username"> > <input name="pw1" type="password"> > <input name="pw2" type="password"> > </form> > > Possible uses for such a form: > > 1. The first pwfield is for the user's password, and the second pwfield is for > the user's PIN (or some other secondary authentication). We want to fill the > first field with the one password we store with the login. (The user will have > to enter the 2nd auth manually, unsupported). > > 2. This could be a poorly designed change-password field, without confirmation. > We want to fill in the first field, and the user will enter their password in > the second field (and pray they don't make a typo!) > > 3. This could be a properly-designed change-password field, where the user is > already known to be logged in (or otherwise has access to change the password), > so the current password is not needed and we should ideally not fill in > anything. > > You seem to have case 3 here. Normally this is just a bit of an inconvenience, > because we've filled in the old password and the user is going to clear that > out and enter their desired new password twice. Unfortunately the page is > trying to be clever, and has already filled in your old password twice. [I'm > guessing that internally it's always "changes" your password to the same value, > or treats old == new as a special case and does nothing.) > > In other circumstances we might not be able to fix this without breaking other > cases (due to the ambiguity noted above), and the page would have to add > autocomplete=off as a workaround. But I think we can do the right thing here, > because the fields already have a password set -- we just shouldn't clobber > them. > > This is basically what bug 327977 does, for password-only forms. This patch > extends that to cover forms that have a username too. [This patch is on top of > bug 327977 and bug 400795.] > > Gavin, does this seem sensible? > Justin, please see the screenshot from the page(attached). the username and two password fields are only visible when SNMP v3 is selected, and please NOTE that they are pre-filled with my login information for this web site. the SNMP username/password has nothing to do with the credentials I use to login into Cacti. I realize it might look the same from FF3 point of view when it renders the page, but as dcarru mentioned earlier, FF2 didn't see it that way, and IE too. so, obviously FF3 scans the page for those fields differently.
Comment 9•16 years ago
|
||
Comment on attachment 329567 [details] [diff] [review] Patch v.1 I think there are other things going on with this bug, so I'm moving the patch over to bug 446109 where it can be tracked separately.
Attachment #329567 -
Attachment is obsolete: true
Attachment #329567 -
Flags: review?(gavin.sharp)
Reporter | ||
Comment 10•16 years ago
|
||
(In reply to comment #9) > (From update of attachment 329567 [details] [diff] [review]) > I think there are other things going on with this bug, so I'm moving the patch > over to bug 446109 where it can be tracked separately. > So, Justin, which version of FF this patch will be implemented in?
Assignee | ||
Updated•16 years ago
|
Product: Firefox → Toolkit
Comment 11•16 years ago
|
||
just watching this bug as a friend is waiting for the fix.
Comment hidden (spam) |
Updated•6 years ago
|
Component: Password Manager → Password Manager: Site Compatibility
Depends on: 1247245
Updated•4 years ago
|
Priority: -- → P3
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•