Re: [Bug 18] no record of consensus for force-authenticate

On Oct 28, 2005, at 6:47 AM, Julian Reschke wrote:

>
> Jim,
>
> thanks for doing the "right thing" here. Comments inline.
>
> Jim Whitehead wrote:
>>  ...
>> SOLUTION REQUIREMENTS
>> R1: A client must be able to request an authentication challenge   
>> without causing a state change on the server
>> R2:  The mechanism for the authentication challenge must be  
>> clearly  identifiable within the specification
>> R3: The client must be able to indicate which method the  
>> challenge  pertains to (since this can potentially vary by method,  
>> though it  usually doesn't)
>> SOLUTION PROPOSAL
>> I like the Force-Authenticate header as defined in the current  
>> draft.  I don't like the If approach (submit an If header with a  
>> known bad  lock token, hence the method will fail) for three reasons:
>> * I feel uncomfortable depending on an unintended use of the If   
>> header -- especially for PUT, if a server ever doesn't handle If   
>> correctly, the forcing of authentication could inadvertently  
>> change  the contents of the resource (assuming you'd force  
>> authentication  with a zero length body with PUT)
>
> I don't feel that we should add new features to the spec just  
> because we fear that some servers may not get the existing stuff  
> right. I a server doesn't handle the If header correctly upon PUT,  
> this is a bug that needs to be fixed anyway.
>
> As a matter of fact, of the servers I recently tested (<http:// 
> lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/0328.html>),  
> two were failing here, one of which not doing "If" checks at all,  
> the other one treating unknown state tokens incorrectly. The latter  
> is moddav, the bug is reported in <http://issues.eu.apache.org/ 
> bugzilla/show_bug.cgi?id=37288>, and Joe Orton has already attached  
> a proposed patch.
>
> The other servers (SAP Netweaver, Xythos, MS IIS) work as expected.
>
>> * It depends on the execution order of authentication vs. If  
>> header  processing within servers (I note this was rebutted in:
>> http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/  
>> 0335.html  and I also note that mod_dav does do authentication  
>> checks  before If checks)
>
> Yep. Is anybody aware of servers working differently.
>
>> * It's a really obscure way of satisfying the requirements (i.e.,  
>> it  fails requirement R2)
>
> That can be fixed by putting that as note into an appendix.
>
>> My strong preference is for a new mechanism here (Force-  
>> Authenticate), though I could perhaps be swayed to adding a new   
>> section to the specification that explicitly describes the use of  
>> If  to force authentication, and gives an example of how this  
>> works. I  don't think this mechanism is one that most implementors  
>> would think  of, even if the have a deep understanding of the spec  
>> (like, me, for  example, who never thought of this).
>
> I have no problem adding non-normative text explaining this.
>
> On the other hand I'd really like to hear from those client  
> implementors. After the three years ago, did anybody actually try  
> the solution proposed back then? If not, why not?
>
> Best regards, Julian

> On the other hand I'd really like to hear from those client  
> implementors. After the three years ago, did anybody actually try  
> the solution proposed back then?

No, we didn't try it. The Mac OS X WebDAV file system handles  
challenges as it gets them and uses the protection space/domain rules  
in rfc2617 to determine when the credentials should be sent with a  
transaction.

> If not, why not?

Unlike some other clients, Mac OS X WebDAV file system always takes a  
LOCK on a resource when the file (resource) is opened with write  
access (and if LOCKs are not supported by the server, its a read-only  
mount for us). In addition, when the Mac OS X WebDAV file system is  
told to create a file that doesn't exist, it issues a PUT with a  
content-length of 0 to create an empty resource on the server (thus  
reserving the name space). Since both of those operations generate a  
challenge, we don't have the problem this bug is trying to solve.

- Jim

Received on Friday, 28 October 2005 18:18:20 UTC