failure to skip unknown HTTP authentication schemes in WWW-Authenticate

NEW
Unassigned

Status

()

Core
Networking: HTTP
P5
normal
7 years ago
4 months ago

People

(Reporter: Julian Reschke, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [necko-would-take], URL)

(Reporter)

Description

7 years ago
See <http://greenbytes.de/tech/tc/httpauth/#multibasicunknown2>. This generates

  WWW-Authenticate: Newauth realm="newauth", Basic realm="basic"

The recipient should skip the unknown scheme, and pick "Basic" instead. It does work when the order is reversed.
(Reporter)

Updated

7 years ago
OS: Windows 7 → All
Hardware: x86 → All
(Reporter)

Comment 1

7 years ago
It appears that the right thing happens if the server sends the two challenges in separate headers:

  WWW-Authenticate: Newauth realm="newauth"
  WWW-Authenticate: Basic realm="basic"

However, this is not supposed to make a difference.
The reason for this treatment seems to be what the comment for nsHttpHeaderArray::MergeHeader() says:

   // Special case these headers and use a newline delimiter to
   // delimit the values from one another as commas may appear
   // in the values of these headers contrary to what the spec says.

The Digest auth being a perfect example of this. Skipping an unknown auth with comma separation is therefore a really nasty task.

Also, I've never seen a live server out there send WWW-Authenticate: headers merged into one, they seem to always send separate lines. Possibly because of the same reason.
(Reporter)

Comment 3

4 years ago
(In reply to Daniel Stenberg [:bagder] from comment #2)
> The reason for this treatment seems to be what the comment for
> nsHttpHeaderArray::MergeHeader() says:
> 
>    // Special case these headers and use a newline delimiter to
>    // delimit the values from one another as commas may appear
>    // in the values of these headers contrary to what the spec says.

Do we have an example of a case like this? (Reminder: Safari and Konqueror get this right).

> The Digest auth being a perfect example of this. Skipping an unknown auth
> with comma separation is therefore a really nasty task.
> 
> Also, I've never seen a live server out there send WWW-Authenticate: headers
> merged into one, they seem to always send separate lines. Possibly because
> of the same reason.

It would be awesome if we could find out whether this is just due to browser bugs, or because it really *needs* to be special-cased (such as with Set-Cookie).

Comment 4

3 years ago
(In reply to Julian Reschke from comment #3)
> Do we have an example of a case like this? (Reminder: Safari and Konqueror
> get this right).

Safari probably gets this right, because Apple uses it. I found this bug, since I am trying to use the iCloud CardDAV server as addressbook in Thunderbird (via SOGo Connector). The Apple server responds with this:

WWW-Authenticate: X-MobileMe-AuthToken realm="Newcastle", Basic realm="Newcastle"

Unfortunately, due to the X-MobileMe-AuthToken scheme, Thunderbird never opens a password dialog.

I can reproduce this with an ownCloud installation. A normal ownCloud installation can be used as addressbook without any problems, but as soon as you insert something like 'Demo realm="Test"' into the WWW-Authenticate header, Thunderbird doesn't bring up the password dialog anymore.

The same problem exists in Firefox aswell.

Comment 5

2 years ago
I stumbled upon the same issue using Sogo to connect with Apple's contacts server.

RFC7235 says:
 User agents are advised to take special care in parsing the field
   value, as it might contain more than one challenge, and each
   challenge can contain a comma-separated list of authentication
   parameters.  Furthermore, the header field itself can occur multiple
   times.

   For instance:

     WWW-Authenticate: Newauth realm="apps", type=1,
                       title="Login to \"apps\"", Basic realm="simple"

   This header field contains two challenges; one for the "Newauth"
   scheme with a realm value of "apps", and two additional parameters
   "type" and "title", and another one for the "Basic" scheme with a
   realm value of "simple".

      Note: The challenge grammar production uses the list syntax as
      well.  Therefore, a sequence of comma, whitespace, and comma can
      be considered either as applying to the preceding challenge, or to
      be an empty entry in the list of challenges.  In practice, this
      ambiguity does not affect the semantics of the header field value
      and thus is harmless.

So the logic in Mozilla should probably check whether the a comma is followed by a name=value pair (in which case it is a parameter belonging to the preceeding challenge), or it is followed by a single token and a space (in which case a new challenge starts)
Whiteboard: [necko-would-take]
You need to log in before you can comment on or make changes to this bug.