Re: Fetch: HTTP authentication and CORS

On Mon, May 6, 2013 at 10:45 AM, Hallvord Reiar Michaelsen Steen
<hallvord@opera.com> 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>).
>
> So me and Anne have been going a bit back and forth on IRC, we agree on some stuff and disagree on other points - and we fundamentally agree that some implementor review and input would be valuable to really settle a conclusion on how this murky little intersection of specs should work..
>
> So the basic issue is HTTP authentication (cached and/or supplied by JS) with XHR, and its interaction with CORS and other stuff like the anonymous flag and withCredentials.
>
>> 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).
>
>
> So far I agree :)
>
>
>> For CORS, we'd return to the caller right there.
>
> Here I don't agree anymore. If I want to retrieve a HTTP auth-protected resource with XHR from a CORS-enabled server, the natural thing to do seems to try to pass in the user name and password in the XHR open() call. If the script author supplied user/pass and the server says 401 on a request without Authorization: surely the natural next step is to re-try with Authorization:?

If the caller to the XHR.open() call provided a username and password,
then shouldn't the implementation send that information in the *first*
request rather than waiting for a 401?

Well.. first request after having done a preflight which checks that
the server is ok with an Authorization header being specified?

/ Jonas