Closed Bug 283331 Opened 19 years ago Closed 19 years ago

SSPI authentication broken

Categories

(Core :: Networking, defect, P1)

x86
Windows XP
defect

Tracking

()

RESOLVED INVALID
mozilla1.8beta2

People

(Reporter: zzyxx, Assigned: darin.moz)

Details

Attachments

(3 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050222 Firefox/1.0.1
Build Identifier: ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

Firefox doesn't auto-authenticate to the proxy anymore, the user has to give his
username and password.

Reproducible: Always

Steps to Reproduce:
1. I start Firefox

Actual Results:  
I get a dialog-prompt 'Enter username and password for proxy "" at proxy:8080'

Expected Results:  
I should not get an authentication-prompt because Firefox uses SSPI authentication.

This problem does not occur with Firefox-builds from the 1.0 or 1.0.1 branches.
It does occur with the trunk-builds.
Wim: can you provide me with a mozilla HTTP log generated using the trunk build
and firefox 1.0?  instructions for generating the HTTP log can be found here:

http://www.mozilla.org/projects/netlib/http/http-debugging.html

Please upload the log files to this bug report using the "Create a New
Attachment" link.  Thanks!
Attachment #175401 - Attachment description: log using 20050222 trunk-build → http-log using 20050222 trunk-build
had to zip it because the log is bigger than 300 KB
When I cancel all the authentication-prompts, the webpages do load. So it seems
that firefox does do sspi-authentication and unnecessarily keeps asking for
authentication-credentials?
This problem still occurs with trunk-build Mozilla/5.0 (Windows; U; Windows NT
5.1; en-US; rv:1.8b2) Gecko/20050324 Firefox/1.0+
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P1
Target Milestone: --- → mozilla1.8beta2
Wim:

the log files only reveal that automatic NTLM was not used in the trunk build,
but it doesn't show why it wasn't used :-(  very little of this code has changed
between firefox 1.0 and the current trunk, so this bug is very surprising to me.

can you do me a huge favor and try to download older nightly builds to try to
figure when this problem started occuring?  try going back as far as november of
last year to see if that helps.

also can you verify that the "network.automatic-ntlm-auth.allow-proxies"
preference is set to true (using about:config) just to be sure.

thanks!
network.automatic-ntlm-auth.allow-proxies is true.

build "Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8a6) Gecko/20050112
Firefox/1.0+" works fine.
build "Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8b) Gecko/20050113
Firefox/1.0+" has the issue.
Nothing looks suspicious in the CVS checkin logs between those dates :-(
I checked in code to increase the amount of HTTP logging in nsHttpNTLMAuth.cpp
around the problem area.  I hope that this will help me track down the issue. 
Can you please download a new build tomorrow and generate a fresh HTTP log
demonstrating the problem?  Thanks!
also, when you generate the new log file, could you please include
"negotiateauth:5" in the set of logged modules.  thanks!
http-log generated with "set
NSPR_LOG_MODULES=nsHttp:5,nsSocketTransport:5,nsHostResolver:5;negotiateauth:5"

and build "Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8b2)
Gecko/20050325 Firefox/1.0+" from "2005-03-25-08-trunk" directory
Wim, thanks but unfortunately the "2005-03-25-08-trunk" build is too old, and it
doesn't include my changes.  I made changes around 2:30 pm PST, and that build
was generated in the morning at 8 am PST.  If you could grab a trunk build from
today (3/26) or later and repeat the logging that'd be great.
http-log generated with "set
NSPR_LOG_MODULES=nsHttp:5,nsSocketTransport:5,nsHostResolver:5;negotiateauth:5"

and build "Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8b2)
Gecko/20050326 Firefox/1.0+" from "2005-03-26-07-trunk" directory
Attachment #178654 - Attachment is obsolete: true
wow, so this little snipet reveals what's going on:

0[2746d0]: nsHttpChannel::GetCredentialsForChallenge [this=20ebc78 proxyAuth=1
challenges=NTLM]
0[2746d0]: nsHttpAuthCache::GetAuthEntryForDomain [key=http://proxy:8080 realm=]
0[2746d0]: nsHttpNTLMAuth::ChallengeReceived [ss=0 cs=0]
0[2746d0]: sys-ntlm allowed for proxy: 0
0[2746d0]:   identity invalid = 1
0[2746d0]: nsHttpChannel::PromptForIdentity [this=20ebc78]

It seems that the pref is not set correctly somehow.  I'm not sure how to
explain this since you said that the pref is set.

Can you try using a fresh Firefox profile?

A quick way to do this is to do the following:

c:\Program Files\Mozilla Firefox\> mkdir test
c:\Program Files\Mozilla Firefox\> firefox -profile test

Then firefox will use "test" to store all of its profile data.
aha, the network.automatic-ntlm-auth.allow-proxies is true for builds without
the problem and false for those with the problem.

sorry, I must have had a firefox without the issue open when i checked the
"network.automatic-ntlm-auth.allow-proxies"-value by mistake.

I see that the file greprefs/all.js has these lines:
// The following prefs are used to enable automatic use of the operating
// system's NTLM implementation to silently authenticate the user with their
// Window's domain logon.  By default, this is disabled for proxy servers due
// to bug 256949.  The trusted-uris pref follows the format of the trusted-uris
// pref for negotiate authentication.
pref("network.automatic-ntlm-auth.allow-proxies", false);
pref("network.automatic-ntlm-auth.trusted-uris", "");

So that's what changed then.

I guess I'l have to read about bug 256949 now...
so, working as expected.  marking INVALID.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → INVALID
see bug 288053 for re-enabling automatic-ntlm for proxies by default.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: