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

To avoid sending the PUT body twice, why can't a client just
use the standard HTTP "Expect 100-Continue" header?

And if a client is proactively checking for authentication preceding
a series of PUT calls, then having it just perform an initial LOCK/UNLOCK
to get the credential challenge doesn't seem like an unreasonable overhead
(2 initial requests).

So is this just a technique for servers that want to provide this
capability but don't want to support LOCK? 

Cheers,
Geoff

Jim wrote on 10/27/2005 08:34:39 PM:
> 
> >
> 
> Julian writes:
> 
> > So this is a process issue -- if it's supposed to become part of 
> > WebDAV, it has to make it through the process of (1) define what 
> > the problem is, then (2) find a WG consensus of how to resolve 
> > this. "Force-Authenticate" may very well be the solution.
> 
> OK, I feel pretty strongly about this feature, so let me do the due 
> diligence here.
> 
> PROBLEM STATEMENT
> 
> Some WebDAV servers are configured to allow live authoring, where the 
> authored changes are immediately visible to the external world. In 
> this situation, resources typically have access controls set such 
> that GET, HEAD, POST, PROPFIND and OPTIONS can be performed by any 
> user without authentication. Write operations such as PUT, LOCK, 
> UNLOCK, MKCOL, MOVE, and COPY require authentication and access 
> permissions. In some cases, a client would do a series of operations 
> that do not require authentication, then perform a PUT of a large 
> resource (this can happen with the common Microsoft Web Folders 
> client). In this situation, the large resource body needs to be sent 
> twice: the initial PUT (which gets a 401 response), and the second 
> PUT, with authentication credentials.
> 
> Ideally, a client would like to test a resource to see whether it 
> should ever send authentication credentials. It is far more 
> convenient for a client author to make a single test at the beginning 
> of a session, discover that some methods will require authentication 
> credentials, and then consistently supply those authentication 
> credentials for every method invocation thereafter. Since a client 
> does not know which authentication scheme is in use, or what nonce 
> values will be used in Digest Auth, it cannot speculatively provide 
> authentication values without receiving a challenge (401) from the 
> server first. While in general it is the case that authentication 
> requirements can vary by method, even on the same resource, this 
> configuration is extremely unusual. Hence, a client that proactively 
> supplies a set of authentication credentials gathered from testing 
> one method that requires authentication (PUT, say), will likely find 
> that these same authentication credentials will work for all other 
> methods (LOCK, UNLOCK, etc.) on the same resource that also require 
> authentication.
> 
> 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)
> * 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)
> * It's a really obscure way of satisfying the requirements (i.e., it 
> fails requirement R2)
> 
> 
> 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).
> 
> - Jim
> 
> 
> 
> 
> 
> 
>