On 8/10/10 15:34 , Anne van Kesteren wrote:
On Tue, 27 Jul 2010 16:32:48 +0200, Yrjänä Rankka
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| gh...@openlinksw.com
Developer, Virtuoso Team | http://www.openlinksw.com
| Making Technology Work For You
