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

RESOLVED FIXED in mozilla1.9beta3

Status

()

Toolkit
Password Manager
P1
normal
RESOLVED FIXED
11 years ago
10 years ago

People

(Reporter: helper4free, Assigned: Dolske)

Tracking

Trunk
mozilla1.9beta3
x86
Windows XP
Points:
---
Bug Flags:
blocking1.9 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

11 years ago
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
(Assignee)

Comment 1

11 years ago
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")?
(Assignee)

Updated

10 years ago
Duplicate of this bug: 412764
(Assignee)

Comment 3

10 years ago
Created attachment 300824 [details] [diff] [review]
Patch v.1
(Assignee)

Comment 4

10 years ago
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.
Attachment #300824 - Attachment is patch: true
Attachment #300824 - Attachment mime type: application/octet-stream → text/plain
(Assignee)

Updated

10 years ago
Assignee: nobody → dolske
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 5

10 years ago
The patch works for me. Thanks!
(Assignee)

Comment 6

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

(Assignee)

Comment 7

10 years ago
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)
(Assignee)

Comment 8

10 years ago
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.
Flags: blocking-firefox3?
Target Milestone: --- → Firefox 3 beta3
(Assignee)

Updated

10 years ago
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+
(Assignee)

Updated

10 years ago
Attachment #300824 - Flags: approval1.9b3?

Comment 9

10 years ago
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
(Assignee)

Comment 10

10 years ago
Checked in.

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

Updated

10 years ago
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.