- From: Adam Barth <w3c@adambarth.com>
- Date: Fri, 3 May 2013 10:32:32 -0700
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: WebApps WG <public-webapps@w3.org>, WebAppSec WG <public-webappsec@w3.org>
Received on Friday, 3 May 2013 17:33:06 UTC
How does withCredentials interact with TLS client certificates? Ideally they wouldn't be used either. Adam 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