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
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 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.
Assignee: nobody → dolske
Status: UNCONFIRMED → NEW
Ever confirmed: true
The patch works for me. Thanks!
Dodot: Oh, awesome, because I don't have an easy way to test authenticating against such a server. Thanks!
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.
Attachment #300824 - Flags: review?(gavin.sharp)
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.
Target Milestone: --- → Firefox 3 beta3
Summary: Modal proxy auth dialog domain\user in username field saving problem → Logins for http/proxy Windows domain (NTLM) auth don't save logins in "domain\username" format
Version: unspecified → Trunk
Attachment #300824 - Flags: review?(gavin.sharp) → review+
Attachment #300824 - Flags: approval1.9b3?
Comment on attachment 300824 [details] [diff] [review] Patch v.1 thnx for the explination Dolske - makes sense - let's get this into B3
Attachment #300824 - Flags: approval1.9b3? → approval1.9b3+
Flags: blocking-firefox3? → blocking-firefox3+
Priority: -- → P1
Checked in. Checking in toolkit/components/passwordmgr/src/nsLoginManagerPrompter.js; new revision: 1.20; previous revision: 1.19
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.