Closed Bug 286628 Opened 15 years ago Closed 13 years ago
NNTP intermittently forgets/deletes passwords (Thunderbird & Sea
I have Thunderbird set to remember my NNTP passwords. Every so often it just deletes them from the file where they are stored and asks me for them upon accessing an NNTP server that requires authentication. Since this is very intermittent, I have not discovered a chain of events that leads to this, but it most definitely is happening.
But you still have all your mail and account settings? That is, it didn't somehow spawn off a new profile -- the profile is generally OK except for the missing passwords? Do you have your passwords protected by a master password? When you notice this have you already entered the master password? just NNTP? It's remembering your *mail* passwords and just forgetting NNTP? That might be a server or communication glitch: if we send a password and the server rejects it I think we'll prompt you. Next time that happens you might try escaping out of the password dialog and coming back to the server at a later time.
No profile issues. What happens is that it will work for a long time (like 6 or 8 months) and then one day it just asks me for a password. When I open the 25714687.s file, there's not even an entry for that host. Yes, the store is protected with a password and encryption.
I see Tbird 1.0.2 on WinME dropping the User ID and Password for news.annexcafe.com frequently. At worst it's every other session. Happens during the inital start sequence, TB is setup to auto query all accounts, both POP and NNTP, for new messages. I have to have the use/pass to enable my access to server staff working groups.
This is being reported with great frequency in the newsgroups for Comcast. It seems that periodically, after a user has succesfully authenticated to the news server and has been using it for a while, the server requests authentication again. This causes FireFox (and also SeaMonkey) to forget the previously entered user name and password, and prompt the user for it again. If the user name and password were being remembered in the password manager, they are forgotten there, also. What makes the problem particularly eggregious is that the username and password prompts do not contain the previously entered values. The user is FORCED to re-enter them. The values are already "forgotten" by the time that the prompt is presented. The fundamental problem seems to be an assumption made in the mailnews client (or perhapts it is in the password manager) that if the server is asking for authentication again, after having previously authenticated (or previously attempting authentication) with the previously stored password, then the previous values must be bad, and so it intentionally forgets them. Note that the same behavior is observed/reported by FireFox & SeaMonkey users for passwords remembered for websites. If a web site requests authentication again, after a previously remembered password has been used to authenticate, then the previous password is forgotten. One thing is clear, this is driving people away from FireFox and Seamonkey. People complain about it in newsgroups, and users of other products say "it doesn't make MY news reader forget the password". I consider this to be a major problem for FireFox users of comcast's NNTP server.
Severity: normal → major
*** Bug 271593 has been marked as a duplicate of this bug. ***
*** Bug 314495 has been marked as a duplicate of this bug. ***
changing summary to include NNTP - each protocol (IMAP/POP3/NNTP/SMTP) has to handle passwords itself. IMAP and POP3 have been fixed to reprompt with the previously sent password in cases where we can't tell bad passwords from other authentication errors, but NNTP hasn't been changed.
Summary: Thunderbird Intermittently "forgets" Passwords → Thunderbird Intermittently "forgets" NNTP Passwords
*** Bug 340950 has been marked as a duplicate of this bug. ***
*** Bug 256051 has been marked as a duplicate of this bug. ***
*** Bug 254486 has been marked as a duplicate of this bug. ***
*** Bug 266828 has been marked as a duplicate of this bug. ***
*** Bug 278318 has been marked as a duplicate of this bug. ***
(In reply to comment #7) > IMAP and POP3 have been fixed [...] but NNTP hasn't been changed. Sounds like you know what to do, could it be fixed for thunderbird 2? If it's simple we'd take it in a 1.8.0.x release, too.
Assignee: dveditz → bienvenu
I think you know this, but the "forgetting" occurs if the server re-requests authentication for ANY reason, such as timeout, or after too many connections, or after accessing a newsgroup with special authentication requirements. Will this fix be in code that is common to FireFox and SeaMonkey? (I hope so)
I don't understand how Firefox is involved. It would be common to Seamonkey (i.e., backend news code)
I can certainly try - however, I don't have ready access to any password-protected newsgroups, so it's difficult to test anything.
Sorry, I meant Thunderbird and SeaMonkey.
I could test when I'm home, my ISP has a contract with newsguy.com (the passwords only work from an IP address on the ISP's block). How do you force an error, though?
(In reply to comment #18) > I could test when I'm home, my ISP has a contract with newsguy.com (the > passwords only work from an IP address on the ISP's block). How do you force an > error, though? See https://bugzilla.mozilla.org/show_bug.cgi?id=256051#c9 in bug 256051. That bug has unfortunately been marked as a duplicate of this one even though it's the other way round; it's almost a year older. If it doesn't make sense to invert the incorrect duplicate decision, the discussion or at least its content should be copied to here.
(In reply to comment #19) > That bug has unfortunately been marked as a duplicate of this one even though > it's the other way round; it's almost a year older. If it doesn't make sense to > invert the incorrect duplicate decision, the discussion or at least its content > should be copied to here. Moreover, you lose the votes accumulated by that bug. When a bug is marked as duplicate of another bug their votes should be accumulated.
(In reply to comment #20) > Moreover, you lose the votes accumulated by that bug. > When a bug is marked as duplicate of another bug their votes should be > accumulated. I filed just such a bug (Bug 25950) more than 6 years ago.
I've voted for this as I hope to have this fixed in SeaMonkey as soon as possible (the password questions suck!). As I don't use Thunderbird and as it may help others finding this bug: May someone add SeaMonkey to Keywords or Summary?
I'm on Comcast, and so have had more than my share of this bug. I believe it could be replicated by trying to log in to an NNTP server with the connection momentarily severed. In my home the problem is repeatable. Got a good 9xxxxxxxx.s file. Open T-bird, collect mail from two accounts, perhaps read News @ moz.org, then try to log on to Comcast's server. Asks for user name, and then PW. Each time checking off to save in PW manager. If server is up, no problem, but dialogue itself indicates a problem. Anyway, fail to connect= blowing away good password with user name, even if I hit cancel right away. Tis first bug report I've filed since a couple of computers ago. Tried to change OS above, but not to be. I am on a MacBook Pro running updated OS X.4 John McWilliams
Product: Thunderbird → Core
Summary: Thunderbird Intermittently "forgets" NNTP Passwords → NNTP intermittently forgets/deletes passwords (Thunderbird & SeaMonkey)
Component: Security → Networking: News
this is similar to the changes I made to the pop3 and imap code - remember the last username and password we've sent to the server, and pre-fill the username and password prompts with those strings. Also, don't remove user names and passwords from the password manager if we've successfully authenticated in the current app session, unless it fails twice. Together, these two changes should make the problem more bearable.
Attachment #226345 - Flags: superreview?(mscott)
(In reply to comment #24) > Also, don't remove user names and > passwords from the password manager if we've successfully authenticated in the > current app session, unless it fails twice. I think it should never remove user names and passwords without user authorization. If there is an authentication problem, I want to try to authenticate with the old username and password (without having to retype them) as long as I'm not persuaded it is not a temporary problem but they are really wrong.
I think the same than Alessandro Staltari :) I'm suffering this under SeaMonkey :s
Attachment #226345 - Flags: superreview?(mscott) → superreview+
I've checked that patch in on the trunk. I'd love some feedback as to whether this helps before landing it on the branch.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
(In reply to comment #27) > I've checked that patch in on the trunk. I'd love some feedback as to whether > this helps before landing it on the branch. > It is better than before but I think it needs some work on it. In brief: - Username and password should never be silently removed. If the user really want to remove them, he can use the password manager. - When the programs prompts for username and password it correctly shows the field filled with the previously saved values, but the "remember" check box is unchecked. I think that if there was already a previously saved username/password then the "remember" checkbox should be enabled by default because probably this is what the user want. Moreover I'm afraid that if the user just confirms the prefilled values by clicking OK but forgets to check the "remember" checkbox, the values will be lost.
I'm not sure we have control over whether that check box is checked for remember password. If anyone wants to whip up a patch to prompt the user if we should remove the password, that would be great. I'll land what we have so far on the 1.8 branch.
changes landed on 1.8 branch as well.
*** Bug 343861 has been marked as a duplicate of this bug. ***
David, I have a question about the expected effect of this change on the user's experience when the NNTP server re-requests authentication. Previous to this patch, the effect was that the user saw a authentication dialog that requested him to enter: - user name (blank) - password (blank) - check box for using password manager to remember (unchecked) - OK or Cancel buttons What is the expected new effect? a) same dialog but name and password filled in with existing values? b) NNTP client silently retries NNTP request reusing existing values?, c) prompting for master password IFF too much time has elapsed since it was last entered, then silently retrying with existing values? d) prompting for master password IFF too much time has elapsed, then same dialog but name and password filled in with existing values? e) other? I expected the answer to be "a" or "d", or even "b" but it seems to be "c" in my testing with recent trunk nightlies. This makes me wonder if I'm seeing the effects of the fix, or some other phenomenon. (BTW, even "c" is a huge improvement over the old behavior!)
e), which is really b, d, and a, depending on circumstances. I wouldn't expect c) either... If an authentication fails, check if the previous authentication worked. If it did, next time silently re-use the previous username and password, but first clear the flag that says the previous authentication succeeded. If the previous authentication failed, then clear the previous username and password from the password manager so we don't automatically send them again. If there wasn't a previously successful authentication, we'll use the password manager to get the password, which will cause the master password check, if required. We will also pass in the last known username and password to the dialog. It would be interesting to know, perhaps from a protocol log, if you're getting multiple failed authentication attempts in a row...
Flags: blocking126.96.36.199? → blocking188.8.131.52+
Comment on attachment 226345 [details] [diff] [review] some improvements approved for 1.8.0 branch, a=dveditz for drivers
Attachment #226345 - Flags: approval184.108.40.206+
fixed for 220.127.116.11
*** Bug 220010 has been marked as a duplicate of this bug. ***
there are two topics I did not see any comment deal about, and I wonder if new patch would have a "good" reaction in these cases: - user initially entered a bad password (miss-speling) - password have been changed on server any way to get notification of that ? any automatic way to get TB ask for a new password ? about comment 33: what about if server has failure ? down time ? I have lived two cases where ThunderBird bored me so much I had to close it. I need it all the time open for mail purposes, but it bored me for NNTP reasons: - news server was down, and TB kept popping me up about unreachable things (ok, that was not password related, but was still boring). - server was listenning on NNTP port, but internal SHADOW service was down, so that authentification to NNTP Server was impossible. in the second case, I fear that process proposed in comment 33 leads to re-asking password every 15 minutes ( 3 times 5 minutes, since it will take 3 turns before an error leads to really re-asking user password, 5 minutes cause thats my refresh-timeout). NIS server have been down half the day; I also had to close TB, thus closing my email client for "news reasons". I know nothing is perfecxt in this world; I just tend to foresee problems before they occur, and try to prevent and limit bugs. Good luck in solving this bug :S
Can people who have been able to reproduce this problem in Thunderbird, please check in Thunderbird 2.0 rc1 <http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/18.104.22.168-candidates/rc1/> and report back here?
I did not have this bug recently ... at least for past 6 months, maybe 1y (Gentoo unstable => latest version).
(In reply to comment #38) > Can people who have been able to reproduce this problem in Thunderbird, please > check in Thunderbird 2.0 rc1 > <http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/22.214.171.124-candidates/rc1/> > and report back here? > Well, the main problem of Thunderbird forgetting the UID and Password is fixed. HOORAY!! Man I'm happy! Major kudos to the developers here. There is still a problem with a timeout error in the write-only newsgroup. Depending on where you're coming from this is either a bug or it's by design. I think most users would consider this a bug, but a different one to be filed separately. Right now I really don't care about the timeout error and I can totally live with it as it doesn't seem to hinder usability. Irregardless, I consider bug 286628 to be completely closed as of Thunderbird 2.0 rc1.
verifying for thunderbird 126.96.36.199 rc2 based on comments. If you disagree and can reproduce with a current rc2 build <http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/188.8.131.52-candidates/rc2/>, please let us know.
Would the latest changes have made it into SeaMonkey 1.1.1? Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:184.108.40.206) Gecko/20070221 SeaMonkey/1.1.1 Things seem to have been *much* better lately, but this afternoon, my increasingly unreliable (and maybe soon to be replaced) news service threw some "server busy - please try later" errors as I hit get messages for all accounts. I was prompted several times for password. No preset ***** value, "remember" unchecked. Didn't exactly remember the password, at first, so made several attempts. I _think_ I got the password right on the last go, but don't think it got messages. A while later (normal poll interval?) I got prompted for BOTH username & password and the values WERE preset. Don't remember what the "remember" checkbox was. Checked it (if it wasn't already checked) and hit ok. Got articles. Sorry this is vague, but I didn't have my troubleshooting hat on when this happened.
The patch is to mailnews which I think is in SeaMonkey as well. This sounds a lot like what David described in comment 33. Still sounds like the patch is behaving as intended. David?
yes, I think so.
I'm sorry, I could not test it before, I find password management is better now, but there are still problems. As far as I can see, when an authentication error happen previously saved usename and password are preset in the authentication dialog only if a previous authetication attempt was succesful. This means, for example, that if start thunderbird and the first authentication attempt fails, the prompt will be empty and, even worst, previously saved credentials are lost. Even if you had a successful authentication before and you get username and password preset in the prompt, I'm afraid they will not saved back to the password store unless you can authenticate successfully (this is a problem if authentication fails because a server error and you quit thunderbird before the server problem is solved). IMHO, clearing the previous saved username and password is never a good idea, I think propting the user is enough. Moreover, if the user had his username and password saved before, we could figure he would want to save the new ones again, so it could be nice authentication dialog have the "remember" checkbox already cheked in this case (the user is still be frustrated because of the authentication error, don't annoy him more than necessary). What do you think?
Bug is fixed on trunk.
Just want to add that back in comment #42, I did get preloaded user & password, once I successfully connected. My experience matches Alessandro's in #45. If this is the current state of this bug, I consider it better, but not fixed. Alas (for this bug anyway), I've changed news provider and should not be in a position to test as often. :)
This bug has not been fixed as of Thunderbird 220.127.116.11. I just got "nntp server busy, try again later.". Then Thunderbird raised the panel: "enter user name for nntp server x". Examination of the password list shows username/password for server x has been deleted by Thunderbird.
David, is it possible that this was fixed on the trunk but not for 2.0.0.x ?
What Axel doesn't say is if whether the previous password was in the password prompt as **** or not. If so, then the patch is on the branch. Comment #40 certainly implies that is. There might also be different scenarios where the bug still occurs...
(In reply to comment #50) > What Axel doesn't say is if whether the previous password was in the password > prompt as **** or not. If so, then the patch is on the branch. Comment #40 > certainly implies that is. > > There might also be different scenarios where the bug still occurs... > I always see "*******" in the password prompt panel, when I have entered the password. I just discovered that password manager shows both user and password as undefined. This bug is new since I moved to 2.x . I can use the nntp server but have to enter user/pw each time I launch Thunderbird. It seems that every user/pw (smtp, imap) entered with 2.x are undefined. The platform here is Mac OS X (10.4.10). Good luck, Axel
(In reply to comment #51) > (In reply to comment #50) > > What Axel doesn't say is if whether the previous password was in the password > > prompt as **** or not. If so, then the patch is on the branch. Comment #40 > > certainly implies that is. > > > > There might also be different scenarios where the bug still occurs... > > > I always see "*******" in the password prompt panel, when I have entered the > password. > I just discovered that password manager shows both user and password as > undefined. > This bug is new since I moved to 2.x . I can use the nntp server but have to > enter user/pw each time I launch Thunderbird. It seems that every user/pw > (smtp, imap) entered with 2.x are undefined. > The platform here is Mac OS X (10.4.10). Good luck, Axel > I just learned that I must authenticate to view the password column in the password manager. With 2.x entered passwords the username column contains <undefined> and username and password are in the password column in separate rows. Hope that helps, Axel
> With 2.x the username column contains <undefined> and username and > password are in the password column in separate rows. Yeah, That's VERY unfortunate, IMO. And different uses of the stored passwords do it differently, e.g. name and passwords are recorded there differently for web pages than for NNTP and SMTP. :( Don't know why SMTP+NNTP can't do it like it was designed/intended.
Note that this bug has become unfixed, again, on the trunk. :( Password manager forgets saved passwords the first time the server doesn't accept them. See bug 437930
You need to log in before you can comment on or make changes to this bug.