Subject: [http-auth] - Debugging and Firefox

From: Damian Gruber <[email-masked]>
Date: Mon, 19 May 2014 08:31:48 +0200

Hi,

I'm implementing a server which does digest access authentication, 
accroding to RFC 2617.
Unfortunately I don't have an (implemented) corresponding client, which 
makes debugging and testing a bit difficult.
Therefore, I'm using Firefox as a user agent, to get at least a bit of 
information.

I hit on three problems, could you have a look at them?

1) It seems that if my server sends out a wrong rspauth-field in the 
Authentication-Info header, a user using Firefox does not get informed 
that the server didn't properly authenticate itself.
Is this true?
Does Firefox even check whether the rspauth-field is as expected?

2) If the user tries to access "/login", the server sends back a 
response which contains the following field in the WWW-Authenticate header:
domain="/login /protected"
After a successful authentication, the user then tries to access this url
"/public/area/"
Firefox also sends the Authorization header for this request, even if 
this url is not in the list from the WWW-Authenticate header, right?

3) Is there some debug output from Firefox, which I can access?

Thanks!

---

From: Gary Mort <[email-masked]>
Date: Mon, 19 May 2014 13:23:58 -0400

On 05/19/2014 02:31 AM, Damian Gruber wrote:
> Unfortunately I don't have an (implemented) corresponding client, 
> which makes debugging and testing a bit difficult.
Don't know, but the code is found here: 
http://mxr.mozilla.org/comm-central/source/mozilla/netwerk/protocol/http/nsHttpDigestAuth.cpp#161

Considering that there are lots of comments like

215  <http://mxr.mozilla.org/comm-central/source/mozilla/netwerk/protocol/http/nsHttpDigestAuth.cpp#215>      // we do not support auth-int "quality of protection" currently

and

226  <http://mxr.mozilla.org/comm-central/source/mozilla/netwerk/protocol/http/nsHttpDigestAuth.cpp#226>  #if0

I'd say it's safe to say that client authentication of the server is 
broken in many ways.

All of this links back to "generateCredentials"

91  <http://mxr.mozilla.org/comm-central/source/mozilla/netwerk/protocol/http/nsIHttpAuthenticator.idl#91>      string  <http://mxr.mozilla.org/comm-central/ident?i=string>  generateCredentials  <http://mxr.mozilla.org/comm-central/ident?i=generateCredentials>(in     nsIHttpAuthenticableChannel  <http://mxr.mozilla.org/comm-central/ident?i=nsIHttpAuthenticableChannel>  aChannel  <http://mxr.mozilla.org/comm-central/ident?i=aChannel>,

I've noticed that in the google chrome code, there is a lot of 
over-reliance on the cache - and that anytime credentials aren't 
returned by some authentication handler, chrome will fall back to 
pulling the last data from the cache.  So as long as the last data in 
the cache will be accepted by the server, it will keep going.

I haven't done a lot of work with the Firefox code.

Another oddity I found in the chrome code[which was mainly copied from 
the firefox code] is that for a given domain name, the browser will only 
cache one set of credentials.

Ie credentials cached for http://www.example.com/~bob , realm="bobs 
virtual server"

After connecting to htttp://www.example.com/~alice, realm="alices 
virtual server"

The credentials for bob's virtual server are lost and will have to be 
re-entered.

> this url is not in the list from the WWW-Authenticate header, right?

Both Chrome and Firefox ignore the Domain header, see 
https://code.google.com/p/chromium/issues/detail?id=74590&q=http%20auth%20digest&colspec=ID%20Pri%20M%20Iteration%20ReleaseBlock%20Cr%20Status%20Owner%20Summary%20OS%20Modified

> 3) Is there some debug output from Firefox, which I can access?

There are a few auth extensions already written in the extension directory.
For example, here is some code:
https://addons.mozilla.org/en-us/firefox/files/browse/130396/file/chrome/content/overlay.js#top

Basically, just write a small extension which listens for the "load", 
"unload", and "http_on_modify_request" events and then you can set your 
javascript debugger to break at those function points in your extension 
and examine what header fields are set at those points.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 19 May 2014 11:43:27 -0700

This is the wrong forum for this discussion.  If you have concrete
issues, might I suggest that you take those to
https://bugzilla.mozilla.org/.

On 19 May 2014 10:23, Gary Mort <[email-masked]> wrote:
> I'm implementing a server which does digest access authentication, accroding
> to RFC 2617.
> Authentication-Info header, a user using Firefox does not get informed that
> the server didn't properly authenticate itself.
> Is this true?
> 215     // we do not support auth-int "quality of protection" currently
>
>
> and
>
> 226 #if 0
>
>
>
> I'd say it's safe to say that client authentication of the server is broken
> in many ways.
>
>
> 91     string generateCredentials(in    nsIHttpAuthenticableChannel
> aChannel,
>
>
> I've noticed that in the google chrome code, there is a lot of over-reliance
> on the cache - and that anytime credentials aren't returned by some
> authentication handler, chrome will fall back to pulling the last data from
> the cache.  So as long as the last data in the cache will be accepted by the
> server, it will keep going.
>
> Another oddity I found in the chrome code[which was mainly copied from the
> firefox code] is that for a given domain name, the browser will only cache
> one set of credentials.
>
> Ie credentials cached for http://www.example.com/~bob , realm="bobs virtual
> server"
>
> After connecting to htttp://www.example.com/~alice, realm="alices virtual
> server"
>
> 2) If the user tries to access "/login", the server sends back a response
> which contains the following field in the WWW-Authenticate header:
> Firefox also sends the Authorization header for this request, even if this
> url is not in the list from the WWW-Authenticate header, right?
>
>
> javascript debugger to break at those function points in your extension and
> examine what header fields are set at those points.
>
>
> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth
>

---

From: Damian Gruber <[email-masked]>
Date: Fri, 23 May 2014 08:46:01 +0200

Hi,

Thanks a lot for your reply!

Basically, my problem is to debug my server.
I agree, Firefox might not be the right choice.

I'm now trying to debug it with cURL.
But also there, it seems that my server can send an arbitrary rspauth 
field, and the user does not get informed about a wrong rspauth field.

Do you have an idea of how I can debug my server, especially find out 
when a rspauth-field is wrong?

Am 19.05.2014 19:23, schrieb Gary Mort:
>> Therefore, I'm using Firefox as a user agent, to get at least a bit 
>> of information.
>>
>> Authentication-Info header, a user using Firefox does not get 
>> informed that the server didn't properly authenticate itself.
>> Is this true?
> 91  <http://mxr.mozilla.org/comm-central/source/mozilla/netwerk/protocol/http/nsIHttpAuthenticator.idl#91>      string  <http://mxr.mozilla.org/comm-central/ident?i=string>  generateCredentials  <http://mxr.mozilla.org/comm-central/ident?i=generateCredentials>(in     nsIHttpAuthenticableChannel  <http://mxr.mozilla.org/comm-central/ident?i=nsIHttpAuthenticableChannel>  
> aChannel  <http://mxr.mozilla.org/comm-central/ident?i=aChannel>,
>
> the firefox code] is that for a given domain name, the browser will 
> only cache one set of credentials.
>
> "unload", and "http_on_modify_request" events and then you can set 
> your javascript debugger to break at those function points in your 
> extension and examine what header fields are set at those points.
>