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

No it's not just for LOCK and PUT -- a client doing read-only requests 
(like PROPFIND) might see different results depending on whether or not 
they're authenticated.  Some of the resources in a collection might be 
publicly readable (so the PROPFIND can succeed if anonymous) but others 
be hidden to unauthenticated users.

More generally, it's not actually a WebDAV problem alone.  If a client 
does a GET to a dynamically generated page, they could easily see 
different results based on whether they're authenticated or not.  Since 
browsers today often cache authentication information, this means that 
the browser could inform the server that they'd like the challenge to 
save the user the step of first going to the site, seeing the anonymous 
page version, then choosing to login.  Of course some sites use cookies 
for this but cookies are sometimes disabled, expired, etc.

Lisa

On Oct 28, 2005, at 8:06 PM, Geoffrey M Clemm wrote:

>
> 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
>  >
>  >
>  >
>  >
>  >
>  >
>  >