359933 - Password for proxy to Internet not stored in TB1.5 due to accents sent back by proxy

Status: RESOLVED WORKSFORME

(Thunderbird :: Security, defect)

Description

[klint]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1) Gecko/20061010 Firefox/2.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.0.8) Gecko/20061025 Thunderbird/1.5.0.8 ID:2006102517

I'm reporting an error in the internet proxy authentication with TB 1.5 (also happening in TB2.0a1).

The corporate proxy I'm using at work sends French accentuated characters in its response (when asking for proxy username and password).

But, and this is the bug I'm reporting, the server name associated to the username&password in the Password Manager screen is either stored wrongly, or retrieved/compared wrongly the next time I want to connect using the proxy (of course, I have checked the "keep password" option). So it is seen as new, and I have to re-type my username&password everytime I launch TB. 
So boring !

See here the screen copy here (in French, sorry !!) : http://klint.free.fr/2006-11-08_095547.png . Look at the Chinese characters (although of course no Chinese character is sent back by the French proxy). It seems that the beginning of the message is ok, up to the first accentuated character).

This is an old bug in TB 0.xx that had been corrected in TB 1.0.x. But it's apparently back since TB 1.5 and still there in TB2a1 

Reproducible: Always

Steps to Reproduce:
1. Launch TB
2. At startup, TB will check the internet for new extension. Login/Password of my Internet Proxy (which has set up in the Option dialog) are asked
3. I enter my login/pwd, check the "Remember password"...
4. Exit TB, launch again


Actual Results:  
5. The password pop up appears again, and is empty ! You have to type in again and again...
6. Now looking at the Password Manager shows that something has been stored, the welcome message from the proxy, but with Chinese characters starting where the first accent in French is encountered

Expected Results:  
The password popup should appear already populated !
and the stored password should not show these Chinese characters

Comment 1

[David :Bienvenu]

this is probably a dup of an existing bug. There's some confusion about whether passwords are utf8 encoded, between wallet and mailnews, iirc. There's a patch somewhere that fixes this - I have to go find it...unfortunately, the fix touched a lot of interfaces and code, so it would be nice to find a simpler fix...

Comment 2

[qxie1]

This probably is related to (or the same as) a bug I was about to report. But I think this bug goes beyond accentuated characters.

I am using TB-1.5.0.8 on PPC/Mac OS. After TB starts up and tries to get through my corp web proxy (wwwgate0.xyz.com:1080) for the first time (for example, to display a mail with remote images), it gives me a pop-up saying "Enter username and password for proxy "Xyz Inc." at wwwgate0.xyz.com:1080" and asking for User Name/Password, and offering the "Use Password Manager ..." check box. This part is fine.

However, after entering the username/password with the "Use Password Manager ..." box checked, the same pop-up comes up again. Apparently, TB is trying to go though the same web proxy again to fetch a different piece of the remote images in the mail, but fails to match the proxy with the one it just stored. A close exame at the pop-up shows why - it says this time "Enter username and password for proxy "" at wwwgate0.xyz.com:1080". Note the empty proxy name this time. I think either the web proxy is careless in attaching its name in all its responses the exactly same way, or TB has a bug extract ing the proxy name from some responses. I guess TB includes both the proxy address (wwwgate0.xyz.com:1080) AND the proxy name in its comparison to determine whether the proxy is known or new. The end result is that TB fails to recognize in my case the proxy is a known one.

What makes the problem worse is that, when I enter the username/password and ask to store them for this "new" proxy (that would be work around), TB apparently suddenly realizes that this "new" proxy is the same as the stored proxy at the time it tries to store the username/password and thus refuse to store them. So the same pop-up just keeps coming again and again.

The simplest/cleanest fix probably is just not to include the proxy name in the comparison when testing a proxy is known or new. This probably will also fix the accentuated characters.

Comment 3

[kloor68373]

I have exactly the same problem using TB1.5/WinXP in my company. 
The proxy replies with a message using a german umlaut:

Proxy response in plain text and as a hexdump (by ethereal)
========================================================================
HTTP/1.0 407 Proxy Authentication Required
Server: squid/2.5.STABLE5
...
Proxy-Authenticate: Basic realm="-- Nutzung nur f.r dienstliche ...
...
========================================================================
0120  22 2d 2d 20 4e 75 74 7a 75 6e 67 20 6e 75 72 20   "-- Nutzung nur 
0130  66 fc 72 20 64 69 65 6e 73 74 6c 69 63 68 65 20   f.r dienstliche 
========================================================================

the pasword entry in pwd manager dialog is broken exactly at the character on position 0x131 in the trace above.

I also remember that the same problem existed in very early versions of Firefox about two years ago but was fixed.

Comment 4

[klint]

Hello

I confirmed that it still happens to me with TB2beta1 latest nightly (2007010904).

(And I confirmed that it was once solved in TB 1.0, but then came back with TB 1.5)

Comment 5

[klint]

Confirmed for released TB 2.0.0.0 .
And to keep the record alive ;)

Comment 6

[kloor68373]

Confirmed for Version 2.0.0.0 (20070326) on XP Pro
Behaviour hasn't changed since this version.

Comment 7

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Reporters, does this still occur in the latest supported Thunderbird 2.0.0.x or trunk nightlies?

(This should be confirmed if it still occurs in the latest builds)

Comment 8

[kloor68373]

This behaviour seems little different but is still faulty in TB 2.0.0.12 (20080213) on WinXPPro. 
First I had to clear the pssword list before my test. It wasn't possible! Deleting process always stopped after the faulty entry. 
I had to delete PW file *.s in my profile dir manually. After entering my credentials it was displayed ok in pw list. But the pw wasn't stored correctly as I noticed after my restart. I was forced to re-enter it. After re-entering it on my second restart after deleting the *.s files I had one false and one correct entry for the same credentials, see http://img134.imageshack.us/my.php?image=tbdm5.png
This behaviour (delete file + 2 restarts) is exactly reproducible (with exception of the erronous characters of the broken entry after the umlaut). I tried it 3 times. Each time it produced one correct entry the first time and one false the second time.

Comment 9

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Confirming based on comments 5, 6 and 8.

Comment 10

[Wayne Mery (:wsmwk)]

Is this still seen in v3.0 and v3.1?

Comment 11

[klint]

Hi wayne
Actually, I personally can't test it anymore as my company has removed mandatory authentication on the Internet proxy in the meantime..
I'm sorry.

Comment 12

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

kloor68373, can you still reproduce this issue with 3.0.x or 3.1 nightlies?

Comment 13

[kloor68373]

Hi Gary, on my

Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1

storing the proxy password now works fine. Thanks.

But there is another issue concerning authentication which I will report in a separate issue: As a result of having a big number of rss feeds which connect simultaneously on thunderbird startup, a corresponding number of authentication dialog windows appear and must be confirmed individually with the (now correctly stored) credentials.