Closed Bug 669675 Opened 11 years ago Closed 1 year ago
failure to skip unknown HTTP authentication schemes in WWW-Authenticate
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.
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.
(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).
(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.
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)
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P5
This is causing real-life compat problems, per the dev-platform thread with subject "nsIHttpChannel not trying to authenticate if presented BASIC and an unknown auth method". We should re-evaluate the priority.
Priority: P5 → --
This needs a broader discussion and checking on how other browsers behave in various scenarios.
Priority: -- → P2
Whiteboard: [necko-would-take] → [necko-triaged]
Junior - can you investigate how Chrome behaves in this situation and report back?
Assignee: nobody → juhsu
Firefox and Chrome behaves the same as Comment 0.
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/42561f42313d Use Tokenizer in ParseRealm r=necko-reviewers,dragana
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/d920aa17a468 Use Tokenizer in ParseRealm r=necko-reviewers,dragana
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/e92759eacf36 Use Tokenizer in ParseRealm r=necko-reviewers,dragana
You need to log in before you can comment on or make changes to this bug.