- 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>
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