409146 - Logins for http/proxy Windows domain (NTLM) auth don't save logins in "domain\username" format

Status: RESOLVED FIXED

(Toolkit :: Password Manager, defect, P1)

Description

[helper4free]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9b2) Gecko/2007121120 Firefox/3.0b2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9b2) Gecko/2007121120 Firefox/3.0b2

I'm using the Firefox behind the corporative proxy. The LAN is using the domain, but I'm log in locally and forced to use "domain_name\user_name" syntax in the proxy authentification modal window. New Firefox 3.02b stores only the "user_name" part of that string. So in the next restart I'm getting prefilled modal window with the only "user_name" and password but no "domain_name\" part in username field. So authentification failed and I'm forced to add "domain_name\" manually every time.

Reproducible: Always

Steps to Reproduce:
1. Create new blank profile
2. Specify the proxy
3. Try out any web site
4. In the modal window user syntax "domain_name\user_name" for the username
5. Specify password
6. Click "Save password" to store password
7. get the requested web site (to see that I'm not mistaken with username|password)
8. close firefox 
9. start firefox with profile created in the 1 step
10. try to open any Internet web site

Actual Results:  
Getting the prefilled modal window with the only "user_name" and password but no "domain_name\" part in username field

Expected Results:  
Getting the prefilled modal window with the only "domain_name\user_name" and password

If I fill in correct domain_name\user_name and press OK then everything allright and I'm getting the requested web site.

If I push "Cancel" button and another modal dialog appear and if I put the correct values for it i'm passing through too. But the another one password saving panel is appear. So I'm get two records for 1 proxy address (with only different headers in "(...)" ) like a

url | username

moz-proxy://some.proxy.address:8080 (PROXY Squid proxy-server) | domain_name\user_name
moz-proxy://some.proxy.address:8080 (moz-proxy://some.proxy.address:8080) | user_name

Comment 1

[Justin Dolske [:Dolske]]

I assume this worked as expected in Firefox 2? Specifically, what do you see filled in for the username in the prompt, and what's the username being stored ("domain\user" vs. just "user")?

Comment 3

[Justin Dolske [:Dolske]]

Attachment: Patch v.1

Comment 4

[Justin Dolske [:Dolske]]

Comment on attachment 300824 [details] [diff] [review]
Patch v.1

(Bah, pressed enter too soon.)

I've seen this problem mentioned a few times, I think this should fix the problem.

Comment 5

[Dodot]

The patch works for me. Thanks!

Comment 6

[Justin Dolske [:Dolske]]

Dodot: Oh, awesome, because I don't have an easy way to test authenticating against such a server. Thanks!

Comment 7

[Justin Dolske [:Dolske]]

Comment on attachment 300824 [details] [diff] [review]
Patch v.1

Basic description of what was happening:

The code expects stored usernames for NTLM (?) logins in the form "domain\user". The existing _SetAuthInfo chops up that string to set aAuthInfo.username and aAuthInfo.domain. Unfortunately, the code to do the reverse never existed, so the "domain\" part wasn't saved.

Looks like this was missed during the original switch to nsIPromptService2, as the old trunk C++ passwordmanager didn't do this either.

Comment 8

[Justin Dolske [:Dolske]]

Requesting blocking beta 3 to get this on the radar.

It's a low-risk patch -- HTTP Windows domain authentication is fairly rare, and this patch doesn't change how normal HTTP logins are saved. The rationale for getting this into Beta 3 is that it's hard to get real-world testing on this, and so having it in for a beta cycle would helpful to shake out any other problems in this area.

Comment 9

[Mike Schroepfer]

Comment on attachment 300824 [details] [diff] [review]
Patch v.1

thnx for the explination Dolske - makes sense - let's get this into B3

Comment 10

[Justin Dolske [:Dolske]]

Checked in.

Checking in toolkit/components/passwordmgr/src/nsLoginManagerPrompter.js;
  new revision: 1.20; previous revision: 1.19