Re: [xhr] RFC2617 Digest authentication

On Tue, 27 Jul 2010 16:32:48 +0200, Yrjänä Rankka <ghard@openlinksw.com>  
wrote:
> Please correct me if I'm wrong, but as I read the XHR level 2 draft, it  
> seems impossible to do Digest auth with custom mechanism for acquiring  
> the authentication credentials. I.e. supplying your own login dialog.
>
> To correctly digest authenticate, one needs to be challenged by the  
> server first. To do that one needs to attempt to invoke a method on a  
> resource without, or with invalid credentials. The resulting 401  
> Unauthorized reply then contains the challenge with nonce, opaque, etc.  
> values required to produce correct reply.
>
> In order to inhibit the browser from prompting the credentials from  
> user, one must define user, password in call to open() method. My  
> observations show this will produce a basic Authenticate: header in the  
> request thus leaking the user/password out in the open even though the  
> server might refuse Basic auth.

I believe some of the browsers wait to be challenged first, actually. That  
is what should happen per XMLHttpRequest.


> Many servers do and should refuse HTTP Basic auth over a non-encrypted  
> connection. This is required by WebDAV [1], for example.
>
> Now it may be possible to trick some of the clients into Digest  
> authentication without prompting the user by first calling open() with  
> bogus user/password - then catching the 401 reply and on subsequent try  
> call open() again with correct user/password values, hoping that the  
> client cached the challenge. This would qualify as a hack, though, since  
> AFAIK this behaviour is not prescribed by the Draft.
>
> I have no problem with rolling my own Digest authentication routines in  
> the client but this would require a clean flag in the XHR to disable any  
> attempt to do authentication on its behalf. Then again, another flag  
> forcing the XHR to only authenticate when challenged, and then choose  
> the strongest available method, as required by rfc2617 [2] would be  
> preferable and would make it easier for developers to use a standard  
> authentication method, reusing what's already implemented in most  
> (modern) clients.

We might add such a flag and a flag to control redirects in the future,  
but not for now.


> [1] http://www.webdav.org/specs/rfc4918.html#rfc.section.20.1
> [2] http://tools.ietf.org/html/rfc2617#section-4.6


-- 
Anne van Kesteren
http://annevankesteren.nl/

Received on Tuesday, 10 August 2010 13:34:45 UTC