Re: [Ietf-http-auth] Clients desiring to authenticate

On Jan 5, 2006, at 2:23 PM, Joe Orton wrote:

> On Thu, Jan 05, 2006 at 10:33:13AM -0800, Lisa Dusseault wrote:
>> Thanks for your thoughts on the authentication stuff, Joe, but I
>> certainly disagree at a most fundamental level about whether it's
>> something clients need to be able to do.  Browsers might not need to 
>> do
>> so, but I can think of cases where that would be useful for browsers
>> too, and it's definitely useful for authoring clients where
>> authorization info is usually necessary to do write operations.
>>
>> Consider some of the WebDAV clients that I'm familiar with:
> ...
>
> None of this has anything to do with "pre-authenticating" in HTTP.
>
> If your application is designed such that it cannot interactively 
> prompt
> users for credentials when challenged, fine, the app must request those
> credentials from the user ahead of time.

This isn't necessarily an application that can't interactively prompt 
users for credentials.  This is an application that, in addition to 
that, can save credentials as preferences, and to save the user from 
confusion (either from seeing incomplete information or to know what 
parts of the UI to enable) would like to perform operations with the 
maximum permissions available.

Have you ever seen an application where certain menu functions, buttons 
or form areas were greyed out or disabled based on what permissions 
were available?  I can read my colleague Ted's calendar as I'm 
subscribed to it via Apple's iCal.  Yet I can't add notes to his 
events, move them around, or add new events, and the UI makes that 
clear (e.g. New Event is greyed out in the menu).  But let's say Apple 
wanted to add the feature that if Ted grants write permission to me, to 
write his publicly-viewable calendar.  How would Apple's client know 
what to grey out?

>  That is purely an application
> design problem, it doesn't imply that the user agent must send those
> credentials to the server *before it is challenged to do so*.
>
>> I also disagree about your reading of 2617. The text is "If the origin
>> server does not wish to accept the credentials sent with a request, it
>> SHOULD return a 401 (Unauthorized) response. " Isn't ignoring the
>> credentials the same thing as "not wish to accept"?  How can you
>> justify accepting a bogus username and password except by entirely
>> ignoring it?
>
> The server has no basis on which to validate the credentials, and hence
> do anything other than ignore them.

My statement would go like "The server had no basis on which to 
validate the credentials, and hence do anything other than fail the 
request."

> It *cannot* form a valid WWW-Auth
> challenge because it has not been configured to do so.  Follow your
> argument through as if you were going to implement it server-side: what
> challenge do you expect the server to send?  It cannot make one up out
> of thin air.

All of the servers I've worked on had the ability to put together a 
valid WWW-Auth challenge for any resource on the server (IIS, Exchange, 
Xythos WebFile Server, Cosmo).  I can certainly understand some Web 
servers don't even have user logins and thus can't form a challenge, 
and for those Web servers presumably ignoring the Authorization header 
could be considered somewhat reasonable.  But that isn't the case with 
the server we tested against, www.webdav.org.  I know that server has 
the ability to put together a challenge because if I formulate a PUT to 
one of its pages it does challenge me.  In this specific example, isn't 
it wrong for www.webdav.org to simply ignore the auth attempt?  What 
should www.webdav.org do if I send a request with my real username but 
an incorrect password?

>
>> But we can certainly quibble about *how* the problem is solved, I care
>> more *that* the problem is solved -- for HTTP, WebDAV, CalDAV and
>> others.  Would you feel it was still a hack if the client used what
>> had previously been a legitimate username (at least for elsewhere in
>> that domain)?
>
> If we're not talking about the "I don't want to have to send the 100MB
> PUT body twice in case I get a 401 the first time" problem (which is
> what I presumed that Appendix D was really about), I don't know what
> problem you're talking about.

It's really more about the PROPFIND returning different results 
depending on how the client is authenticated, and the WebDAV ACL "what 
permissions do I have" request returning different results depending on 
how the client is authenticated.

Lisa

Received on Thursday, 5 January 2006 22:38:28 UTC