213282 - mozilla not sending basic authorization header

Status: RESOLVED FIXED

(Core :: Networking: HTTP, defect, P1)

Description

[Petr Kures]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030720 Mozilla Firebird/0.5 StumbleUpon/1.63
Build Identifier: http://ftp.mozilla.org/pub/mozilla/nightly/2003-07-19-04-trunk/

In recent Mozilla (and Mozilla Firebird) builds (tested with Mozilla
2003071008,2003071904 and MozillaFirebird from 20030711) NetWare Remote Manager
(Netware 6 + SP3) https access does not work. After entering username and
password, I get three blank frames instead of management portal. In builds
before (including) 20030630 it has worked. I have created http debug log and in
newer builds Authorization header is sent only in first request and not in
subsequent requests.
I'll attach debug log files with http headers.

Reproducible: Always

Steps to Reproduce:
1. enter netware management portal address (https://)
2. enter username and password

Actual Results:  
Only frameset with three empty frames have loaded.

Expected Results:  
NetWare management portal should have loaded.

I have deleted profile and mozilla instalation directory completely before testing.

Comment 1

[Petr Kures]

Attachment: httplog with older Mozilla build (20030630) - working

This is the http debug log created with Mozilla 20030630, to login to Netware
Management Portal works without problem with this builds (and maybe few after
this date).

Comment 2

[Petr Kures]

Attachment: http log with Mozilla build (20030719) - fails

In this build login to management portal never finishes. Mozilla is trying to
load frames and CSS, but since no authorization header is sent, the management
protal just redirects the browser to https://192.168.0.2:8009/_LOGIN_SERVER_.

Comment 3

[Jo Hermans]

Can Netware use NTLM authentication ?

Comment 4

[Jo Hermans]

If this server is using NTLM (Netware 6, or 5.1 with access pack), then you
might have to have to enter the name as domain\username. We don't have a
separate field for the domainname yet, see bug 199674.

Comment 5

[Petr Kures]

No, it uses basic authentication over SSL. 
The problem is not in the authentication credentials, they are generated ok and
accepted by the server, but the Authorization header is being sent only in the
first request (GET /)after authentication and not in subsequent requestes (like
GET /SYS/LOGIN/portal.css).

Comment 6

[Darin Fisher]

this looks like a major regression to me... probably resulting from the fix for
bug 143575 :(

Comment 7

[Petr Kures]

You are right. The problem is result of fixing bug 143575.
The problem is in nsHttpChannel.cpp and have been caused by this change (maybe
there are more problems, but I tested only this):

     rv = authCache->GetAuthEntryForPath(host, port, path, &entry);
     if (NS_SUCCEEDED(rv)) {
+        // if we are trying to add a header for origin server auth and if the
+        // URL contains an explicit username, then be sure to try the given
+        // username first.
+        if (header == nsHttp::Authorization) {
+            nsHttpAuthIdentity temp;
+            GetIdentityFromURI(0, temp);
+            if (nsCRT::strcmp(temp.User(), entry->Identity().User()) != 0)
+                return; // different username; let the server challenge us.
+        }

GetIdentityFromURI returns empty nsHttpAuthIdentity. This means that temp.User()
is not the same as entry->Identity().User() and the function returns without
setting Authorization header. I replaced the return; line with:

LOG(("usernames do not match (%x,%x)\n",temp.User(),entry->Identity().User()));

and I've got this line in my http log:

usernames do not match (0,21a26d8)

With this modification the login have succeeded.

Comment 8

[Darin Fisher]

ok, so probably we just need to equate an empty string with a null string.  no
surprise now that i think about it.  this sort of problem has always plagued the
HTTP auth code :-/

patch coming up...

Comment 9

[Petr Kures]

I think that we need to check if temp.User() is empty (this means no
username:password in URI) and in that case just continue and use username and
password from entry->Identity().User(). In the case that temp.User() contains
username that have been parsed from the URI, compare it with
entry->Identity.User() and return if not equal.

So the code should probably (IMHO) look like this:

if (header == nsHttp::Authorization) {
  nsHttpAuthIdentity temp;
  GetIdentityFromURI(0, temp);
  if (temp.User() && nsCRT::strcmp(temp.User(), entry->Identity().User()) != 0)
        return; // different username; let the server challenge us.
}

Comment 10

[Darin Fisher]

Attachment: v1 patch

petr: can you please test this out?

Comment 11

[Petr Kures]

I have applied your patch and executed:

cd /netwerk/protocol/http/src
make
cd /netwerk/build
make

Is this the right way to rebuild just the modified component ?

I have tested mozilla with newly built necko.dll and the authentication to the
portal now works.

Comment 12

[Darin Fisher]

excellent, thank you petr!  (yes, you rebuilt necko correctly.)

Comment 13

[Darin Fisher]

*** Bug 214138 has been marked as a duplicate of this bug. ***

Comment 14

[Darin Fisher]

fixed-on-trunk

Comment 15

[Darin Fisher]

*** Bug 216979 has been marked as a duplicate of this bug. ***