Closed Bug 96896 Opened 23 years ago Closed 22 years ago

News reprompts for user name/pwd on reconnect rather than using values from the password manager

Categories

(MailNews Core :: Networking: NNTP, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 36816

People

(Reporter: dean-elhard, Assigned: sspitzer)

References

Details

From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.3+) Gecko/20010823 BuildID: 2001082303 It seems that mail/news does not go back to the password manager for the username/password when re-establishing a timed out session, but instead prompts the user for them Reproducible: Always Steps to Reproduce: 1. open the folder for a NNTP server which: a) requires user authentication b) has a user name and password already stored in the password manager 2. select a group to bring up the list of articles. 3. wait long enough for the NNTP connection to time out 4. select an article to display or a different group on the same server Actual Results: mail/news pops up the dialogs asking for the username and password, even though the values are already stored in the password manager , (and were used for the initial access to the server) Expected Results: The connection should be re-established whithout prompting me for information it already has.
I'm not seeing this with build 2001-08-28-03 using internal auth newsgroup: news://poisonivy.mcom.com/xrated. On Windows 2000, when I force my network connection to drop using ipconfig/release, and then doing an ipconfig/renew, I see other strange things (like cache issues with the postings, but I'll file that seperately). Can you telnet to your server (for me, I do telnet poisonivy.mcom.com 119) and tell me what kind of server this is? Thanks.
Summary: News reprompts for user name/pwd on reconnect rather than using values from the password manager → News reprompts for user name/pwd on reconnect rather than using values from the password manager
The response from the server on connect is: 200 enews1.newsguy.com NNRP server INN 1.90.02 15-May-01 ready (posting ok). I have been assuming that it is a timeout of the connection which causes the problem. I haven't tried watching the tcp status to confirm that, but it does seem to be very reliable that if I leave mailnews up in a newsgroup while I work on something else and then come back to it again, it prompts for username and password which it shouldn't. I will try doing a bit of experimentation with mozilla and netstat to see if it does correspond to the connection being dropped.
Confirming, even though I can't reproduce this in-house, I've seen numerous bugs reported against password not being remembered (or, the simple re-prompting)
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** This bug has been marked as a duplicate of 98029 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Not a dup of that bug. Re-opening...
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
If you are interested the linux version to the latest CVS has the same problem. I'm entering this with a home built executable dated 2001121917
OS: Windows 2000 → All
Hardware: PC → All
I'm seeing it on 0.9.8 Win32 as well... Comcast is now providing access to Usenet for it's fairly sizable population of (former @Home) cable modem users via GigaNews, so there may be more people running in to this. Hitting the NNTP port I get: 200 News.GigaNews.Com (Typhoon v1.2.3)
I was granted access to news.cis.dfn.de which requires userid and password. What I see is that I get repeatedly asked for userid + password. I don't know if it is when the server times out. I don't know how I can tell. In any case if you check "make pwm remember" or whatever that checkbox says you will get repeated entries in the pwm db, and you can see them when you "manage passwords". I hope to hear about it when this is not the same bug.
Related to bug 46118?
*** Bug 116493 has been marked as a duplicate of this bug. ***
Marked nsbeta1- per MailNews Triage.
Keywords: nsbeta1nsbeta1-
*** Bug 132160 has been marked as a duplicate of this bug. ***
Not sure whether I should comment here or on 34506 or 36816, but I have a similar problem that makes USENET reading a major PITA with mozilla. Despite having told it to save the username and password to my news server, it randomly "forgets" them (after a NNTP timeout?) and/or says authentication rejected. I noticed that the password manager has multiple entries -- news://awd42_007@verizon.net:119/#password, news://awd42_007@verizon.net:119/#username, and these two entries for a couple of different groups that I've had to re-authenticate to after a timeout or something (I subscribe to more than these groups BTW). The problem is my username is NOT awd42_007 (that's what's in front of the '@' in the email I use with news), but passwd manager sure thinks it is for some reason. Telnet to news.verizon.net on port 119 shows: 200 This connection cequired username/password authentication. (Twister v2.0.5.1)
*** Bug 171620 has been marked as a duplicate of this bug. ***
*** Bug 177175 has been marked as a duplicate of this bug. ***
Blocks: 95397
*** Bug 149609 has been marked as a duplicate of this bug. ***
*** Bug 181048 has been marked as a duplicate of this bug. ***
*** Bug 182733 has been marked as a duplicate of this bug. ***
This has been known for over a year, what's the ETA for a fix? It's rather annoying.
*** Bug 185446 has been marked as a duplicate of this bug. ***
*** Bug 185607 has been marked as a duplicate of this bug. ***
*** Bug 185427 has been marked as a duplicate of this bug. ***
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2.1) Gecko/20021130 Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2.1) Gecko/20021130 Have to disagree that this is a timeout issue, but rather an issue of password manager storing duplicate entries for the server (for sending responses, showing groups, subscribing) and entries for each group (on the assumption that all id/passwords will be the same for all groups?) Added and used a single group with no issues for about two months, but when I attempted to add a second group on the same server with a different id/password, password manager began requiring full login for every action on the server. Investigation showed that when a group is subscribed to with id and password, password manager creates four entries, two for the server, and two for the group with the same information. Problem begins with the addition of another group as that process appears to add two entries for the new group with the new information and that it changes the previous server userid/password information. Password manager does not allow any edit of this information, which might not even help if it were possible. If "server" entries are deleted, multiple groups can be added and read, but response transmissions fail. It's a royal pain, but response submissions can then be "edited as new" from the "Sent" folder, the new "Reply to" address removed and the re-send will (eventually) succeed. Think that this could be solved by allowing the user to add a new "News Account" but when that is attempted, it is refused by Mozilla because the server already exists in the previous account. Another clue is that as part of this process, hourglass appears in header window and remains until the reader is closed and re-launched. Note also that there is a very similar problem reported in a "Keychain???" bug report... sorry, don't have the number here. Beverly Howard
I totally disagree. This happens on newsservers that require only *one* user/password for all groups, and where definitely only one password is stored in password manager (for the server itself, not for individual groups). This also happens when password manager isn't involved at all, aka the password never gets stored by mozilla. This also happens on pushed auth, aka when the newsserver never actively requests user/password. All above said, this is neither a problem related to stored passwords in any way, not is it a connection issue. It's a plain issue that Mozilla, although it's never shutdown, doesn't reuse once entered passwords for newsgroups during the same session, and even seems to forget that a password was ever entered. For instance, on a server with pushed auth activated, open groupA. Mozilla will aks for user/password. Works. Wait 5 minutes. Now open GroupB on the same newsserver. Mozilla will again ask for user/password. Wait again 5 minutes. Open GroupA again. Mozilla will *again* ask for user/password (note I'm saying *pushed* auth, this user/pass request *never* comes from the server, it's plain inside Mozilla only!!!). DO the same above *without* waiting the 5 minutes between switching groups, and you'll only have to enter the credentials once. It's some sort of internal timeout in Mozilla that sort of invalidates the entered password for *different* groups on the same Newsserver. If you stay inside *one* group, you'll never have to reenter the credentialy, no matter how long you're idle. Additional Info: If you let password manager store a password *for the root* of the newsserver, you'll still be unable to switch groups. However, if you go back to the newsserver root between switching groups, it will work.
Folks, see also bug 36816, which, when fixed, would probably clear up this issue once and for all.
Per my observations with the passwords, I went back and took the following steps and observations. The following is for a news server that requires a different id/password for each section Unsubscribed from all existing sections Removed all stored passwords associated with removed sections Subscribed to first section Logged on and gave userid and password and checked save password Password manager showed two entries (id/password) for the section, not the server Read Messages Responded to Messages Checked password manager and no change (two entries for section) Subscribed to second section Logged on and saved passwords Password manager showed two additional entries for the new section Posted a message Password manager now showed two additional entries FOR THE SERVER in addition to the four previous entries. Access Denials and manual logon prompts begin here and make access to this specific server impractical
Keywords: mozilla1.0.1mozilla1.3
*** Bug 189721 has been marked as a duplicate of this bug. ***
*** Bug 186489 has been marked as a duplicate of this bug. ***
*** Bug 191284 has been marked as a duplicate of this bug. ***
Using FizzillaMach/2003021017, this now seems to work. I seem to recall trying this less than a month ago and it still not working, so maybe it was fixed recently.
Dupe. *** This bug has been marked as a duplicate of 36816 ***
Status: REOPENED → RESOLVED
Closed: 23 years ago22 years ago
Resolution: --- → DUPLICATE
Verified dup
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.