- From: Yrjänä Rankka <ghard@openlinksw.com>
- Date: Tue, 10 Aug 2010 18:01:58 +0200
- To: Anne van Kesteren <annevk@opera.com>
- CC: public-webapps@w3.org
On 8/10/10 15:34 , Anne van Kesteren wrote: > 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. > > Yep. Most seem to do this after all. I think what I was seeing was caused by the realm in question having previously presented a basic authenticate challenge only, and the browsers in question caching that info. >> 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. > Was worth a try anyway. For sure people shouldn't try and roll their own (often snake-oil -based) auth lightly. Would be great to be able to direct client to refuse BASIC auth over non-TLS wire altogether, though. Yrjänä > >> [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, 10 August 2010 16:02:44 UTC