When I log into one of my embedded linux boxes' web interface, it needs a username but an empty password (HTTP auth). When I enter it, Minefield asks me if I want to store this "password". I click "remember" but nothing happens (the blue stripe doesn't disappear either). The next time I come back, I have to enter my credentials over again: Nothing was saved. Expected behavior: I'd like it to store the username and empty password. Or, second best option, don't ask me if I want to store it in the first place ;)
I'm inclined to WONTFIX this, we already don't save form-based logins when there's no password. There is a bug here, though, in that we shouldn't offer to save the login in this case. :-)
Well, as I said: Second best option, still a bug :) On the other hand, since there obviously *is* a login happening (judging by the fact that a HTTP auth window pops up) I think the pwd mgr should always be able to store what was entered, no matter what it was. This would be consistent. Admittedly: It's a rare use case, anyway. But sounds to me like it may be an easy fix.
This worked in 126.96.36.199 (saved the login). What value is there in NOT saving the login? Was useful to me, and seems like a regression.
I can confirm that this problem still exists in ff3.0rc1. I think empty passwords should be saved too, as it was made in ff2.0. e.g. TWiki has users with empty passwords by default.
I can confirm, the problem exist in ff3.0rc3 too. It is really annoying that every time, when I want to open http://localhost/phpMyAdmin/ I have to type 'root' every time... Empty password is still a password, so I think Firefox should save empty password either.
I had submitted bug 442141 which is a duplicate of this one. I searched before submitting, but obviously not carefully enough. Sorry about that. At the very least, if FF3 isn't going to remember the password, it shouldn't offer to. The existing behavior is misleading.
Assignee: nobody → dolske
OS: Mac OS X → All
Hardware: PC → All
Target Milestone: --- → mozilla1.9.1
Summary: Password manager does not store usernames with empty passwords → Password manager offers to store logins with empty passwords
What about form-based logins?
Form based logins already ignore empty password fields... When _onFormSubmit() is looking for the password fields, it winds up calling _getPasswordFields() with skipEmptyFields == true.
Attachment #337158 - Flags: review?(gavin.sharp) → review+
Pushed changeset b9181db84ccb.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Whiteboard: [need review gavin]
Target Milestone: mozilla1.9.1 → mozilla1.9.1b1
According to bug 499938, this regressed. I still think a username with empty PW should be saved rather than special-cased, but do as you please.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
The changeset pushed for this bug only eliminates saving empty passwords for forms, not for protocol authentication. Thus the reported issue (that the incorrect behavior exists on HTTP Auth) was never actually fixed. Quoting from nsLoginManagerPrompter.js LoginManagerPrompter Implements interfaces for prompting the user to enter/save/change auth info. nsIAuthPrompt: Used by SeaMonkey, Thunderbird, but not Firefox. nsIAuthPrompt2: Is invoked by a channel for protocol-based authentication (eg HTTP Authenticate, FTP login). nsILoginManagerPrompter: Used by Login Manager for saving/changing logins found in HTML forms. By fixing nsLoginManagerPrompter.js, it was assured that no prompts would be issued for empty passwords in HTML forms, but the alternative code prompt for nsIAuthPrompt2 still throws prompts (see starting at line 437). nsIAuthPrompt probably does the same thing (I didn't check). I am willing to write a patch either way we decide to go on this, but I would strongly suggest that we revert the changes made previously on this bug and allow an empty password. Even though it's called password manager, it's really "credentials manager" and a username is still a valid credential. If it's absolutely anathema to allow that, I will write the identical checks into the prompts for the nsIAuthPrompt and nsIAuthPrompt2 sections, but I would urge that taking the alternative course suggested originally in this bug (and in 499938, as well as many of the other dupes). It might not be wise security practice on the part of whatever is asking for authentication, but IMO that's not really our concern.hints at it.
OK, sorry for the spam, 80% of what I said above is wrong. My apologies for the time wasted reading above. The patch was only checked in on trunk, not on the 1.9.1 branch, so I was looking at the wrong files. 499938 isn't a regression, it's invalid, but I do believe that the current behavior is still wrong (that we should save empty passwords.)
Back to WONTFIX, for the same reasons as before.
Status: REOPENED → RESOLVED
Closed: 11 years ago → 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.