Re: Re: Fetch: HTTP authentication and CORS

[Hallvord Reiar Michaelsen Steen]

 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?



I'd like to do that, but Anne thinks it violates the HTTP protocol (and 
apparently is hard to implement on top of certain networking libraries?).


Any networking devs who would like to comment on that?

-- 
Hallvord R. M. Steen
Core tester, Opera Software

Re: Re: Re: Fetch: HTTP authentication and CORS

[Hallvord Reiar Michaelsen Steen]

  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?
  

 I'd like to do that, but Anne thinks it violates the HTTP protocol


Replying to self, this would break the authentication method negotiation that 
HTTP allows (i.e. selection of basic, digest, and more proprietary stuff like 
NTLM). Hence we should wait for a 401 challenge. 


(Could we however fix this in CORS so that the WWW-Authenticate header could be 
included in a preflight response where applicable?)

-- 
Hallvord R. M. Steen
Core tester, Opera Software

Re: Re: Re: Fetch: HTTP authentication and CORS

[Anne van Kesteren]

On Mon, May 6, 2013 at 1:39 PM, Hallvord Reiar Michaelsen Steen
hallv...@opera.com wrote:
 (Could we however fix this in CORS so that the WWW-Authenticate header could 
 be included in a preflight response where applicable?)

Maybe we should wait for actual complaints about XMLHttpRequest + CORS
lacking integrated support for HTTP authentication before complicating
the protocol even more with unused garbage. In other words, given that
the majority of sites are not using a variant of HTTP authentication
at the moment I don't think further enshrining it is worth the cost.


--
http://annevankesteren.nl/

RE: Re: Fetch: HTTP authentication and CORS

[HU, BIN]

If we are talking about RFC2617 HTTP Authentication, there are 2 authentication 
models:

(1) Basic Authentication model:

Under this circumstance, basically client can send the username:password pair 
at the first request, e.g. in the form:

https://username:passw...@www.example.com/path

which in turn maps to an HTTP header

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Where username:password is BASE64-encoded.

Because of the vulnerability of Basic Authentication model (without 
encryption), https is strongly recommended.

But in practice, Basic Authentication is rarely used, and it is mostly based on 
a challenge-response model, where the server challenges with 401 code, and a 
Authentication header to ask for Basic Authentication:

WWW-Authenticate: Basic realm=WallyWorld

(2) Digest Authentication model:

Digest scheme is always based on challenge-response, and server challenges with 
401 code, Authentication heade, and other important information such as nonce, 
e.g.:

 HTTP/1.1 401 Unauthorized
 WWW-Authenticate: Digest
 realm=testre...@host.com,
 qop=auth,auth-int,
 nonce=dcd98b7102dd2f0e8b11d0f600bfb0c093,
 opaque=5ccc069c403ebaf9f0171e9517f40e41

so that client can apply the appropriate digest algorithm, such as MD5, and 
generate the response:

 Authorization: Digest username=Mufasa,
 realm=testre...@host.com,
 nonce=dcd98b7102dd2f0e8b11d0f600bfb0c093,
 uri=/dir/index.html,
 qop=auth,
 nc=0001,
 cnonce=0a4f113b,
 response=6629fae49393a05397450978507c4ef1,
 opaque=5ccc069c403ebaf9f0171e9517f40e41

Because nonce is needed to generate the appropriate digest, the 401 challenge 
is required.

Hope it helps

Bin

-Original Message-
From: Hallvord Reiar Michaelsen Steen [mailto:hallv...@opera.com] 
Sent: Monday, May 06, 2013 11:13 AM
To: Jonas Sicking
Cc: Anne van Kesteren; WebApps WG; WebAppSec WG
Subject: Re: Re: Fetch: HTTP authentication and CORS


 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?



I'd like to do that, but Anne thinks it violates the HTTP protocol (and 
apparently is hard to implement on top of certain networking libraries?).


Any networking devs who would like to comment on that?

-- 
Hallvord R. M. Steen
Core tester, Opera Software