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

Re: [xhr] RFC2617 Digest authentication

From: Yrjänä Rankka <ghard@openlinksw.com>
Date: Tue, 27 Jul 2010 16:32:48 +0200
Message-ID: <4C4EEE10.2020801@openlinksw.com>
To: public-webapps@w3.org
  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 

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.

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.


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

Yrjana Rankka            | ghard@openlinksw.com
Developer, Virtuoso Team | http://www.openlinksw.com
                          | Making Technology Work For You
Received on Tuesday, 27 July 2010 14:33:23 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:26 UTC