263542 - Infinite loop. Bad Passwords aren't cleared if if the username contains a . (dot)

Status: RESOLVED WORKSFORME

(MailNews Core :: Networking, defect)

Description

[graeme worthy]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20040913 Firefox/0.10.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20040913 Firefox/0.10.1

If 'save my password' is checked, and a wrong password is entered, then the Bad
login dialog will close, but it pops back up again as fast as i can close it.
Can't stop this from happening, and had to exit forcefully by killing the process.

I _can_ exit this loop by holding escape, but there should be an abort button of
some sort.

Reproducible: Always
Steps to Reproduce:
1. Try to get mail with a wrong password that is saved.
2. click 'ok' on bad password dialog.
3. watch bad password dialog reopen.
2. click 'ok' on bad password dialog.
3. watch bad password dialog reopen.
2. click 'ok' on bad password dialog.
3. watch bad password dialog reopen.
2. click 'ok' on bad password dialog.
3. watch bad password dialog reopen.


Actual Results:  
Opens a Dialog with only "ok" on it, clicking "ok" doesn't stop the client from
trying to connect, and getting another failure, which opens a new bad password
dialog, repeat untill head bangs against monitor. Can't accesss program menues
when the dialog is open.

Expected Results:  
Open a Dialog with "Bad Password", and then gives user a chance to re-enter
password, or abort the whole process. 


holding escape breaks the loop, but that wasn't immediately evident. And really,
shouldn't be the only solution.

Comment 1

[Christian Eyrich]

We already know such loops but up to now it was AFAIK that the password changed
(or some other error interpreted that way) after a login was successful in this
session at least once.

But after some testing I discovered that it's possible to also create this loop
if one enters a wrong password and "remember my password" is checked *if the
username contains a . (dot)*. Maybe it's also possible with other "unnormal"
characters but I couldn't reproduce with % and @.

To find out what's wrong, it would be nice if you could write what your username
is so I can test this.

Comment 2

[graeme worthy]

well, as a matter of fact the username i used contained both dots and @'s

the server we use requires authentication a user login as follows.

[e-mail]

i hope this helps.

Comment 3

[Christian Eyrich]

(In reply to comment #2)

> the server we use requires authentication a user login as follows.
> 
> [e-mail]

Ok, thanks, that confirms my research.
As far as I can see, forgetting a password (for POP, IMAP, SMTP and NNTP) goes a
way where the username in the uri is converted so that dots are encoded into %2E.
When saving a password dots aren't encoded and so they can't be found when they
should be removed (see singsign.cpp#971).

Usernames when saving the password are escaped through nsEscape() in GetServerURI().
When forgetting they go through
  NS_NewURI(getter_AddRefs(uri), serverSpec); in ForgetPassword()
and
  uri->GetSpec(spec); in nsWalletlibService::Observe()

In spite of reading through RFC 2396 I'm not sure if a dot should get encoded or
not so I can't say if nsEscape() does miss it or URI encodes to much.
Some help from someone who does know would be appreciated.

Comment 4

[David :Bienvenu]

I think '.' and '@' are supposed to be escaped for uri's - cc'ing jshin, who I
think has been involved in escaping issues recently. 

Are we in a situation where we can fix this, without not finding already saved
passwords?

Comment 5

[Christian Eyrich]

(In reply to comment #4)

> Are we in a situation where we can fix this, without not finding already saved
> passwords?

Yes, I guess that will be a problem. The URI for password retrieval is also
generated through nsEscape() in GetServerURI() (e.g.
nsMsgIncomingServer::GetPasswordWithUI around line 846).
So if we'd modify GetServerURI(), passwords with dots won't be found too.

Comment 6

[jwq]

I think the summary is meant to read "Infinite loop. Bad Passwords aren't
cleared if the username contains a . (dot)" Would someone with the appropriate
privs please change the summary if they agree with my reading of this bug.

Comment 7

[Christian Eyrich]

(In reply to comment #6)
> I think the summary is meant to read "Infinite loop. Bad Passwords aren't
> cleared if the username contains a . (dot)"

Right, thanks.

Comment 8

[Scott Davey]

*** Bug 263713 has been marked as a duplicate of this bug. ***

Comment 9

[:aceman]

Does this problem still exist? This would be some bad interaction with the login/password manager from Firefox, so that we need to specially escape the usernames to be able to store or find them in the password manager.

Usernames to mailboxes commonly contain dots as they often are in the form [e-mail] .
I would expect more reports of this if users wouldn't be able to change their passwords in TB.

Comment 10

[Wayne Mery (:wsmwk)]

I've not seen this and don't think this exists.