Re: Markup Validator can not proxy digest auth?

Hello,

On Jan 22, 2007, at 13:20 , olivier Thereaux wrote:
> Conclusion: bad news, everyone, I think we can't "proxy" digest  
> auth - unless I'm mistaken, and trust me, I'd love to be wrong here.

Thanks to all who gave thoughts on this, and corrected my poor  
wording - indeed, it's authentication delegation we're talking about,  
proxying is not the issue.

Jose suggested that some of the features explained in RFC2617 [1]  
could be of help.
[1] http://www.ietf.org/rfc/rfc2617.txt

In particular Jose pointed me toward:
[[
The opaque data is useful for transporting state information around.
For example, a server could be responsible for authenticating content
which actually sits on another server. The first 401 response would
include a domain field which includes the URI on the second server,
and the opaque field for specifying state information. The client
will retry the request, at which time the server may respond with a
301/302 redirection, pointing to the URI on the second server. The
client will follow the redirection, and pass the same Authorization
header, including the <opaque> data which the second server may
require.
]]

This looked interesting. Not so much the use case described here  
(where it's the client eventually retrieving the resource, not the  
server in the middle) but the usage of the "domain" directive.

However, a good look at the spec shows that the "domain" directive is  
only here to tell the client "here are all the URIs you can reuse  
this authentication with", not "here is the URI you should be using  
in your authentication digest".

After a bit of test to check whether my interpretation was correct, I  
can confirm with reasonable certainty that, as I originally thought,  
and many confirmed, there is no way the validator can challenge  
digest auth for /check/?uri=http://www.example.org/ and pass the  
authentication response to retrieve http://www.example.org/, due to  
the way the digest is created.

Sorry this is not good news.
-- 
olivier

Received on Friday, 2 February 2007 02:15:34 UTC