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

Re: Fetch: HTTP authentication and CORS

From: Adam Barth <w3c@adambarth.com>
Date: Fri, 3 May 2013 10:32:32 -0700
Message-ID: <CAJE5ia-q1WtAcfJy4fZ-9TLfFjYj36hSDy4jALX=6RunoCSXsg@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: WebApps WG <public-webapps@w3.org>, WebAppSec WG <public-webappsec@w3.org>
How does withCredentials interact with TLS client certificates?  Ideally
they wouldn't be used either.


On Friday, May 3, 2013, Anne van Kesteren wrote:

> 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 17:33:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:33 UTC