1007707 - Firefox stops HTTP Digest Authentication, after authentication realm has changed and another login is attempted, using URL to provide credentials (http://user:pass@host)

Status: UNCONFIRMED

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

Description

[Janis]

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.132 Safari/537.36 OPR/21.0.1432.57 (Edition Campaign 51)

Steps to reproduce:

I have been applying HTTP Digest Authentication (RFC 2617) with Firefox successfully for many years now.
To simulate a "logout" functionality I use the authentication realm. Once a logout occurs, the current realm becomes invalid and with the next HTTP request, a new realm is sent in the 401-HTTP header.

When using manual entry of username and password, all works as expected.

But recently I tried providing the credentials with the URL (http://user:pass@host):


Actual results:

When Firefox has just started up, it works as expected:
[request the URL: "http://user:pass@host"]
  HTTP request: GET / (without authentication)
  HTTP response: 401 Unauthorized (including realm "realm1")
  HTTP request: GET / (using DIGEST authentication with "realm1")
  HTTP response: 200 OK

This is different when Firefox has already successfully authenticated once and has been running for a while.
Now the "logout" occurs, either active or by waiting for a timeout. This means, the former realm "realm1" is not valid anymore.
After requesting the URL (http://user:pass@host) with correct credentials, Firefox shows the input dialog for user name and password, instead of using the new realm "realm2" to authenticate successfully:
[request the URL: "http://user:pass@host"]
  HTTP request: GET / (without authentication)
  HTTP response: 401 Unauthorized (including realm "realm1")
  HTTP request: GET / (using DIGEST authentication with "realm1")
  HTTP response: 200 OK
[after a while, realm1 becomes invalid, now request the URL again: "http://user:pass@host"]
  HTTP request: GET / (using DIGEST authentication with "realm1")
  HTTP response: 401 Unauthorized (including realm "realm2")
[Firefox shows credentials dialog, instead of using realm2]


Expected results:

What I would have expected, and what Opera (v21) is actually doing well, is Firefox to try and authenticate using realm2:

[request the URL: "http://user:pass@host"]
  HTTP request: GET / (without authentication)
  HTTP response: 401 Unauthorized (including realm "realm1")
  HTTP request: GET / (using DIGEST authentication with "realm1")
  HTTP response: 200 OK
[after a while, realm1 becomes invalid, now request the URL again: "http://user:pass@host"]
  HTTP request: GET / (using DIGEST authentication with "realm1")
  HTTP response: 401 Unauthorized (including realm "realm2")
  HTTP request: GET / (using DIGEST authentication with "realm2")
  HTTP response: 200 OK


This prevents me from seamlessly integrating several web interfaces, the user has to re-enter the credentials at every login, although they have been provided correctly.
A fix would be very much appreciated :-)

Comment 1

[Patrick McManus [:mcmanus]]

can you bisect it?

https://quality.mozilla.org/docs/qmo-community/lesson-plans/how-to-bisect-find-the-culprit/

Comment 2

[Janis]

I'll try, my build environment will be ready soon (hopefully). What would be the next steps?

Comment 3

[Patrick McManus [:mcmanus]]

(In reply to Janis from comment #2)
> I'll try, my build environment will be ready soon (hopefully). What would be
> the next steps?

you'll identify the source of the regression and then we can figure out if we need to fix it, back it out, or on-balance would rather have the patch even with the regression. that can't be done in the abstract.

Comment 4

[Janis]

My first sentence might have been misleading, I don't know if there ever was a Firefox version that implemented the correct behaviour. So rather than trying out old changesets I would like someone with more insight in the sources than me to look into the problem. I could test a possible patch.

I think Firefox stops trying to authenticate too early without realising that the realm has changed, and therefore another HTTP request (with the updated realm) should be performed. Instead, the user dialog is presented (too early in my opinion).

Comment 5

[Janis]

After examining the Mozilla source code a little, I found what I believe to be the position for a fix:

in the function nsHttpDigestAuth::ChallengeReceived() the user identity is declared "not necessarily invalid", if the server sent "stale=true". I think this has to be done as well if the 401-response contains a different "realm" than the originating request. Something like:

nsHttpDigestAuth::ChallengeReceived(..) {
  ...

  nsresult rv = ParseChallenge(challenge, realm, domain, nonce, opaque,
                               &stale, &algorithm, &qop);
  if (NS_FAILED(rv)) return rv;

  if (SUITABLE_STRING_CMP(realm, REALM_USED_IN_REQUEST))
    // if the challenge has the "stale" flag set, then the user identity is not
    // necessarily invalid.  by returning FALSE here we can suppress username
    // and password prompting that usually accompanies a 401/407 challenge.
    *result = !stale;
  else
    // if the realm used in the HTTP request is not identical to the realm
    // in the replied challenge, then the user identity is not necessarily
    // invalid. By returning FALSE here we can suppress username and password 
    // prompting that usually accompanies a 401/407 challenge.
    *result = 0;
  
  ...
}

Comment 6

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 7

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 8

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, untouched DOM/Storage bug's priority.

If you have reason to believe, this is wrong, please write a comment and ni :jstutte.