141605 - Need to work around non-standard Digest auth server implementations [was: Digest Authorization do not quote certain values]

Status: VERIFIED FIXED

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

Description

[George Mount]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020417
BuildID:    2002041711

When using digest authorization, qop and nc values are not quoted:

Here is an example Header value:

Digest username="George Mount", realm="Cougaar",
nonce="fba370c72a9e8e4b8c5f1c6b87e45c69", uri="/$ExerciseOne/user_admin?page=us
erResults&searchTerm=&searchOn=uid&maxResults=100&action=Search",
response="d3d4901f02abcab2025daa846d04c1d9", opaque="3c4f7a4b1e370d9ea61161
fe13a6976f", qop=auth, nc=00000001, cnonce="8b02e3d1e0d10d82"


Reproducible: Always
Steps to Reproduce:
Point your browser to a URL that requires digest authentication. Examine the
header received by the web server (or sent by the browser).

Actual Results:  In the Authorization header, the values for qop and nc are NOT
quoted-strings as required.

Expected Results:  All values in the Authorization header should be quoted-strings.

Comment 1

[Hugh Kennedy]

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

Comment 2

[An-Cheng Huang]

Since bug 150602 was marked as a duplicate of this one, shouldn't we change the
summary to "add special-case support for broken server implementations" or
something like that?

Comment 3

[Darin Fisher]

ok

Comment 4

[An-Cheng Huang]

Attachment: a very small patch implementing the workaround

Basically, if the Server header begins with "Microsoft-IIS", digest auth
inserts extra quotes around the qop-value.

By the way, if there is a way to get the Server header from the nsIHttpChannel
pointer in nsHttpDigestAuth::GenerateCredentials(), then of course the
interface change will not be necessary, and the patch can be made even smaller.

Comment 5

[Darin Fisher]

an-cheng:

thanks for the patch.  you need to use this code to get the Server header from
the HTTP channel:

 {
   nsIHttpChannel *httpChannel = //...

   nsCAutoString serverVal;
   httpChannel->GetResponseHeader(NS_LITERAL_CSTRING("server"), serverVal);
   if (!serverVal.IsEmpty()) {
      //...
   }
 }

Comment 6

[An-Cheng Huang]

Attachment: patch without interface change

this patch uses darin's hint to get the Server header.

(By the way, this is not tested.     Can someone who has an IIS try this patch?
 It's not clear from the descriptions (here and in 150602) whether the NC value
needs to be quoted...)

Comment 7

[An-Cheng Huang]

Attachment: fix typo

oops, "server" -> "Server"

Comment 8

[Darin Fisher]

Comment on attachment 106915 [details] [diff] [review]
fix typo

>Index: http/src/nsHttpDigestAuth.cpp

>+  // IIS implementation requires extra quotes
>+  PRBool requireExtraQuotes = PR_FALSE;
>+  nsCAutoString serverVal;
>+  httpChannel->GetResponseHeader(NS_LITERAL_CSTRING("Server"), serverVal);
>+  if (!serverVal.IsEmpty()) {
>+    requireExtraQuotes = !PL_strncasecmp(serverVal.get(), "Microsoft-IIS", 13);
>+  }

actually, GetResponseHeader is case-insensitive.  "server" is just as good
as "Server", so use whichever one you prefer.


>+    if (requireExtraQuotes) authString += "\"";

how about a line break here?

>+    if (requireExtraQuotes) authString += "\"";

and here?

e.g.,

   if (requireExtraQuotes)
     authString += "\"";

fix that nit, get someone to test the patch, and r/sr=darin

Comment 9

[An-Cheng Huang]

Attachment: cleanup per darin's comments

It would be great if someone who already has an IIS server can test this.   Or
maybe someone can give me a test username/password on an IIS server?

Comment 10

[Darin Fisher]

Comment on attachment 106988 [details] [diff] [review]
cleanup per darin's comments

sr=darin (provided it actually works!)

Comment 11

[Bradley Baetz (:bbaetz)]

Comment on attachment 106988 [details] [diff] [review]
cleanup per darin's comments

Sigh. I don't have an iis server to test on, but I found three ms-based
articles about iis examples, all of which quoted the value here...

r=bbaetz

Comment 12

[Darin Fisher]

fixed-on-trunk

i went ahead and checked this in.  please reopen if you find that this doesn't work.

Comment 13

[An-Cheng Huang]

Thanks darin!  

I was setting up IIS on my "Win2K Professional" but discovered that in order to
use digest auth, "Win2K Server" is required!  (I saw a registry hack somewhere
for converting Professional to Server but didn't look into it...) 

Comment 14

[Eric Hodel]

I'm working against an IIS server that doesn't emit a server header:

HTTP/1.1 401 Unauthorized ( The server requires authorization to fulfill the
request. Access to the Web server is denied. Contact the server administrator.  )
WWW-Authenticate: Digest qop="auth", realm="eportal.paccar.com",
nonce="d6af59f0cc8b3ee77216602000002332195780dbd9fa76b6c5fff30d35f9"
Pragma: no-cache
Cache-Control: no-cache
Content-Type: text/html
Content-Length: 5473
Connection: close

Using a ruby implementation works with a quoted qop, but does not work without.
 Mozilla is sending an unquoted qop value:

Authorization: Digest username="Eric Hodel", realm="eportal.paccar.com",
nonce="4107baa081a592a6021660200000cd6c5686ff5f579324402b374d83e2c9", uri="/",
response="4ce4bba1d67101d8e4107df3d836504c", qop=auth, nc=00000001,
cnonce="082c875dcb2ca740"

I can't get the IIS server changed to emit a Server: header, since I don't
control the box.

Would anything break if Mozilla quoted the auth value by default?

Comment 15

[Darin Fisher]

eric: standards compliant servers would break if mozilla sent a non-standard qop
value.  i think mozilla's default authorization request should follow the
standards to the 'T' except in cases where we know the origin or proxy server
requires a non-standard format.  IOW, without a "Server" header, there is
nothing we can do.

marking FIXED again.

Comment 16

[Eric Hodel]

v.

Comment 17

[Matthew van Eerde]

Can we reopen this?  It's NOT fixed.  See bug #330702

Basically, connecting to an IIS server via Digest authentication only works "sometimes"

See also patch 215309 attached to bug 330702

Comment 18

[Darin Fisher]

Matthew: Instead of re-opening this bug which has been closed for a long time, let's focus on the new bug instead.

Comment 19

[Matthew van Eerde]

Er, never mind, I misread the RFC (egg on my face)

I was looking at the rules for WWW-Authenticate headers and mistakenly applying them to the Authorization: headers.

Firefox is correct.  I have notified Microsoft (via the IE blog) of the three Microsoft bugs reflected in my header trace (two bugs in IIS, one in IE.)