W3C home > Mailing lists > Public > public-webappsec@w3.org > May 2013

Fetch: HTTP authentication and CORS

From: Anne van Kesteren <annevk@annevk.nl>
Date: Fri, 3 May 2013 13:57:46 +0100
Message-ID: <CADnb78jDLm7oOX7g2Vmh-JugC_iqAqnwWi5tD3dTLbG3xN_LNQ@mail.gmail.com>
To: WebApps WG <public-webapps@w3.org>, WebAppSec WG <public-webappsec@w3.org>
I had a discussion with Hallvord on IRC about the exact semantics we
want for HTTP authentication in the context of CORS (and in particular
for XMLHttpRequest, though it would also affect e.g. <img
crossorigin>).

Username/password can be passed via open() or the URL. In that case we
first check if the server challenges us (do a request without
Authorization that results in a response with status 401). For CORS,
we'd return to the caller right there.

If the Authorization header is set via setRequestHeader() we'd treat
it as any other header. We assume the developer already checked if he
was challenged or not, etc.

If an Authorization header was cached for the URL in question
(previous visit) we'd never reuse that under CORS.

This means that withCredentials effectively means "with cookies" (and
we should have called it that, mea culpa).

I'd be great to know if there's consensus on this. General not caring works too.

Context: http://krijnhoetmer.nl/irc-logs/whatwg/20130503#l-318 and onwards.


--
http://annevankesteren.nl/
Received on Friday, 3 May 2013 12:58:13 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:01 UTC