Closed Bug 231042 Opened 21 years ago Closed 21 years ago

cannot remove stored (empty) password

Categories

(Toolkit :: Password Manager, defect)

x86
Linux
defect
Not set
major

Tracking

()

RESOLVED FIXED

People

(Reporter: darin.moz, Assigned: bryner)

References

()

Details

(Keywords: regression)

Attachments

(1 file)

cannot remove stored (empty) password in recent firebird trunk build.

build: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7a) Gecko/20040113
Firebird/0.8.0+

steps to reproduce:

1) set a master password
2) close browser and restart
3) go to https://ites.krcinfo.com/
4) enter username and password on left (doesn't have to be correct)
5) press Login
6) answer yes to the "remember this password" dialog
7) when prompted for master password, press cancel (twice -- that's another bug)
8) close browser and restart
9) goto "Tools->Options->View Stored Passwords"
10) enter master password
11) notice an empty entry for https://ites.krcinfo.com/
12) remove the entry
13) close the dialog, and reopen it
14) notice that the entry for https://ites.krcinfo.com/ is still there!

expected results:  remove the entry

i'm guessing this is a regression because i know i've tried to cancel out of the
master password dialog before without seeing this problem.

this is a serious bug because it somehow prevents the form from working in the
future.  loading the page a subsequent time results in a master password dialog
followed by an odd failure to be able to login.  for some reason, the Login
click doesn't not lead to a form POST.  the click just gets ignored by firebird!
Severity: normal → major
Sounds a lot like bug 221654.  But this bug has steps to reproduce!
Btw, I didn't have a master password when I reported bug 221654.
There are really two bugs here.  We should not be storing a password entry at
all if you cancelled the master password dialog.  And, I suppose we should allow
a blank host+user combination to be removed, in nsPasswordManager::RemoveUser,
in case people already have this situation on their machine.
Looks like Bryner fixed the first bug.  Checkin at 01/16/2004 23:10, "If
encrypting the password fails (such as the user cancelling the master password
prompt), then don't store the password entry."

That leaves this bug (can't remove stored empty u+p combinations) and bug 221654
(can't submit form when there's an empty u+p combination for that form).
Attached patch patch to fix remaining issues (deleted) — Splinter Review
This patch does a few things:

- Guard against adding an empty username and empty password via either of the
AddUser methods.

- Allow removal of an empty-username entry to proceed without trying to decrypt
it.

- Discard entries with an empty username and empty password when reading in the
signons file, and then write it back out without those entries if we discarded
anything.
Checked in.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Blocks: 221654
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: