W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2010

Re: [xhr] RFC2617 Digest authentication

From: Anne van Kesteren <annevk@opera.com>
Date: Tue, 10 Aug 2010 15:34:08 +0200
To: public-webapps@w3.org, Yrjänä Rankka <ghard@openlinksw.com>
Message-ID: <op.vg75a6q364w2qv@anne-van-kesterens-macbook-pro.local>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:40 GMT