Closed
Bug 28941
Opened 25 years ago
Closed 24 years ago
backslash and Double Quote " not escaped for IMAP username Login
Categories
(MailNews Core :: Networking, defect, P2)
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla1.0
People
(Reporter: samw, Assigned: Bienvenu)
Details
(Keywords: imap-interop)
Attachments
(1 file)
2.54 KB,
patch
|
Details | Diff | Splinter Review |
In an MS Exchange IMAP account it is fairly normal for the username to contain \(backslash) characters. Also " (double quote) characters are valid in passwords. The bug with \ in specific to the username entry of the account setup wizard, such that a username DOMAIN\user needs to get into the prefs.js as DOMAIN\\\\user (or needs to be escaped on reading prefs.js). The bug with " is specific to the protocol output of IMAP such that all " characters that are not representing the beginning or end of a password string need to be passed as \" Many thanks Sam Winstanley Senior QA Engineer SPSS Inc. (London,UK)
Comment 1•25 years ago
|
||
No one has looked at this bug in quite a while. Samw, could you download M15 and see if you still find this problem? Confirming this bug since it looks well defined.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reporter | ||
Comment 2•25 years ago
|
||
I can confirm that this is still a bug in the M15 build.
Comment 3•25 years ago
|
||
alecf, would the first part of this bug belong to you in the account wizard? That is, if the user name contains a '\' as in DOMAIN\user, we need to escape that before going into prefs.js. The second part sounds like me or jefft.
Target Milestone: --- → M17
Comment 4•25 years ago
|
||
yes, I think so.
Comment 5•25 years ago
|
||
Okay, re-assigning to alecf to fix the first part. Re-assign to me and I'll fix the protocol part when you are done.
Assignee: mscott → alecf
Comment 6•24 years ago
|
||
moving to M18 and marking nsbeta3 and interop
Updated•24 years ago
|
Status: NEW → ASSIGNED
Updated•24 years ago
|
Priority: P3 → P2
Assignee | ||
Comment 9•24 years ago
|
||
I'll look at this.
Assignee: alecf → bienvenu
Status: ASSIGNED → NEW
Comment 10•24 years ago
|
||
second pass - per mail triage
Whiteboard: [nsbeta3+] → [nsbeta3-][cut 8/29]
Assignee | ||
Updated•24 years ago
|
Status: NEW → ASSIGNED
Comment 11•24 years ago
|
||
Since this bug impacts my use of the mozilla mail agent at work, I tested this today. The account wizard correctly escaped the backslashes in my username when it stored them into prefs.js (Linux/i386 built from cvs this morning) So, it appears that we now need to do the second part (making sure these characters are escaped going over the wire to the IMAP server.
Assignee | ||
Comment 13•24 years ago
|
||
adding keyword
Assignee | ||
Comment 14•24 years ago
|
||
Looks like bug 59231 is a dup of most of this bug (the backslash part) so I'm changing the summary to just the remaining double quote part. Thanks for fixing 59231, Seth.
Summary: Double Quote " and Backslash not escaped for IMAP Login → Double Quote " not escaped for IMAP Login
Reporter | ||
Comment 15•24 years ago
|
||
Ok, I will retest in M15 and M16
Assignee | ||
Comment 16•24 years ago
|
||
What do you mean about testing with m15 and m16? I think this was fixed very very recently, post Netscape 6.0 release.
Reporter | ||
Comment 17•24 years ago
|
||
OK I retested in M18 and the problem is still exists, there is more than one bug here (or there are several parts) and some have been fixed. Firstly on the \ character in logins for MS servers: 1. Do wizard for account setup and enter a username DOMAIN\user 2. username is successfully placed in prefs.js and is properly escaped into DOMAIN\\user (this gets around the javascript need for escaping). 3. Subsequent attempts to read the string from prefs.js are also successful, such that the account properties for the IMAP account display the name as entered, this is also correct. 4. When tracing the IMAP conversation with the server is is clear that the problem is more likely to be in the IMAP protocol handler, e.g. the name is read from prefs.js as DOMAIN\user, this string is not escaped to the IMAP convention which would be DOMAIN\\user it is merely sent as DOMAIN\user. With passwords the same problem exists, passwords are sent as plain text and can contain characters like '\' '"' and these need escaping using the same C/javascript convention before they are sent to the server. Updated the platform to All... I can reproduce this on Linux NT 4.0 and Win2k. The server is MS Windows NT but the client could be any platform.
OS: Windows 2000 → All
Assignee | ||
Comment 18•24 years ago
|
||
by m18, do you mean a daily build from 11/18/00 or later? Because only a build after that would contain Seth's fix.
Comment 19•24 years ago
|
||
I just tested this from a linux/i386 machine. The build is fresh from cvs sources as of this morning. I had the same results that Sam described with M18: the prefs.js file correctly shows the backslashes escaped, but the login fails. I'm trying to figure out how to use something like tcpdump to show the conversation with the IMAP/Exchange server, but haven't managed to see whether the backslashes are being escaped over the wire yet.
Comment 20•24 years ago
|
||
Could it be that Seth's fix is not in the trunk?
Assignee | ||
Comment 21•24 years ago
|
||
I'm pretty sure Seth's fix is *only* on the trunk. Actually, I think I'm an idiot about this - Seth's fix is for passwords, not usernames.
Summary: Double Quote " not escaped for IMAP Login → backslash and Double Quote " not escaped for IMAP username Login
Comment 22•24 years ago
|
||
my fix is on the trunk. henrik gemal has verified it. my fix was only for passwords with a "\" that were sent during insecure imap login. let me go find the bug number.
Comment 23•24 years ago
|
||
for you curious types, the bug was #59231
Comment 24•24 years ago
|
||
I figured out tcpdump. The trunk build I just tested is not escaping the backslashes. # tcpdump -i eth0 -s 2048 -w /tmp/DUMP dst exchng7 ^C when done attempting to authenticate. # strings /tmp/DUMPl\_f l\_fTP l\_fTP 1 capability z\_f z\_f 2 login "Gallup\pohl longsine\pohl_longsine" "********" 3 logout \_gSP
Assignee | ||
Comment 25•24 years ago
|
||
I've taked Seth's fix for login id's and extended it to passwords in the proposed fix I've attached. Can I get some r=?
Assignee | ||
Comment 26•24 years ago
|
||
Assignee | ||
Comment 27•24 years ago
|
||
actually, reverse that, I've taken Seth's fix for passwords and extended it to usernames.
Comment 28•24 years ago
|
||
r=sspitzer
Comment 29•24 years ago
|
||
I applied the patch & built it. It works fine...I can log into my Exchange server. Bravo! 2 login "Gallup\\pohl longsine\\pohl_longsine" "*******" P.S. Could you guys tell me what this supersecret "r=foo" notation means?
Assignee | ||
Comment 30•24 years ago
|
||
r means review, as in code review, reading the code and making sure there's nothing obviously wrong with it. =foo is the person doing the review. thanks for running the code (the true test :-) )
Comment 31•24 years ago
|
||
did this get checked in?
Assignee | ||
Comment 32•24 years ago
|
||
yes, I think so.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 33•23 years ago
|
||
tested on a InterMail IMAP with the password net."scape and it worked... build 20011018
Status: RESOLVED → VERIFIED
Updated•20 years ago
|
Product: MailNews → Core
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•