Ian Hickson wrote:
On Thu, 14 Feb 2008, John Panzer wrote:
Ian Hickson wrote:
On Thu, 14 Feb 2008, John Panzer wrote:
Right, I'm not talking about Access-Control, I'm talking about
general HTTP auth[nz]. I don't understand the rationale for
AC4CSR's policies with regard to the Authorization: header
The rationale is really as simple as this: browser vendors don't want
to enable a distributed user credentials search.
Which could be accomplished by banning Authorization: Basic and
Authorization: Digest only.
Unless there's some other scheme in use that's also vulnerable.
Sure, but one could make the same argument about nonstandard schemes for
any header and any query parameter.
It also wouldn't help in general with XMLHttpRequest, since that blocks
the Authorization: header because it can get set by the user agent due to
the user being authenticated with that site.
For non-CSR XHR, that's not the case in practice or in proposed spec,
right? "UAs /MUST/ set the |Authorization| header according to the
values passed to the |open()
<http://www.w3.org/TR/2006/WD-XMLHttpRequest-20060405/#dfn-open>| method
(but /MUST/ allow calls to |setRequestHeader()
<http://www.w3.org/TR/2006/WD-XMLHttpRequest-20060405/#dfn-setrequestheader>|
to append values to it).
--http://www.w3.org/TR/2006/WD-XMLHttpRequest-20060405/
So technically it wouldn't be blocked, except of course every header is
blocked which is a separate topic on another thread.
This would only really be useful though if Authorization: is allowed to
convey authorization in addition to authentication. Since is used for
authorization in addition to authentication today in practice (AuthSub,
Amazon AWS, OAuth), I'm worried there's a mismatch between what's done
in the field and what the specification calls for, which is resulting in
conflicts.
John
