Closed Bug 141605 Opened 23 years ago Closed 21 years ago

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


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






(Reporter: georgemount, Assigned: darin.moz)



(Whiteboard: [digest-auth])


(1 file, 3 obsolete files)

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
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.
*** Bug 150602 has been marked as a duplicate of this bug. ***
Whiteboard: [digest-auth]
Ever confirmed: true
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?
Summary: Digest Authorization do not quote certain values → Need to work around non-standard Digest auth server implementations [was: Digest Authorization do not quote certain values]
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.

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()) {
Attached patch patch without interface change (obsolete) — Splinter Review
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...)
Attachment #106883 - Attachment is obsolete: true
Attached patch fix typo (obsolete) — Splinter Review
oops, "server" -> "Server"
Attachment #106913 - Attachment is obsolete: true
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?


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

fix that nit, get someone to test the patch, and r/sr=darin
Attachment #106915 - Flags: review-
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?
Attachment #106915 - Attachment is obsolete: true
Comment on attachment 106988 [details] [diff] [review]
cleanup per darin's comments

sr=darin (provided it actually works!)
Attachment #106988 - Flags: superreview+
Attachment #106988 - Flags: review?(bbaetz)
Priority: -- → P3
Target Milestone: --- → mozilla1.3alpha
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...

Attachment #106988 - Flags: review?(bbaetz) → review+

i went ahead and checked this in.  please reopen if you find that this doesn't work.
Closed: 22 years ago
Resolution: --- → FIXED
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...) 
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="",
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="",
nonce="4107baa081a592a6021660200000cd6c5686ff5f579324402b374d83e2c9", uri="/",
response="4ce4bba1d67101d8e4107df3d836504c", qop=auth, nc=00000001,

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?
Resolution: FIXED → ---
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.
Closed: 22 years ago21 years ago
Resolution: --- → FIXED
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
Matthew: Instead of re-opening this bug which has been closed for a long time, let's focus on the new bug instead.
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.)
You need to log in before you can comment on or make changes to this bug.