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

So if you wanted to browse a collection, and see all the 
non-publicly-readable resources alongside the publicly readable 
resources, you'd try to LOCK that collection?  That's actually a state 
change if it succeeds, may have significant side effects.

Expect is a reasonable solution in theory.  However, it's harder to 
implement, which is why a simpler mechanism might see more 
implementation.
   - Expect requires the server to maintain more state, for longer, 
while the client gets back with the rest of the request (when a success 
response happens).  It's unique in splitting the request and response 
up.
  - Expect could be subject to trivial DOS attacks.
   - As Julian pointed out, Java servlet engines don't allow this kind 
of flexibility, while a servlet could implement Force-Authenticate (or 
something similar) without requiring changes in the servlet engine.  
There are probably similar restrictions in other cases -- maybe IIS' 
API, Apache's module API, I don't know.

Are there any other solutions?  To throw out some possibilities no 
matter how cheesy:

1.  A LOGIN method (while it would make purists scream) could be 
defined such that it always caused an authentication challenge.  (It 
wouldn't keep the user logged in for every subsequent request -- only 
requests which continued to have the right auth header from then on.)

2. If the client knows it wants to authenticate, perhaps it could send 
an Authorization header on its very first request.  Because the client 
doesn't want to actually reveal any username or password until it has 
learned the 'realm' value, the header value has to be bogus.

        PROPFIND / HTTP/1.1
        Authorization: Basic BOGUSSTRING:BASE64ENCODED

With Basic, the server either reject Basic auth entirely, or try to 
decompose the string. The username portion would be looked up in the 
user database.  There's always a chance that a valid user name would 
exist for whatever bogus string was chosen.

Using Digest, there's an opportunity to use a bogus realm:

       Authorization: Digest realm="CHALLENGE"

So another variation is to send an Auth header that's neither Basic or 
Digest:

       Authorization: CHALLENGEME

Existing servers would probably return 400 Bad Request or Not 
Implemented to the above 2, so such a plan would have to be widely 
disseminated so servers could change.

All of these Auth header hacks are in some sense inferior to the 
clean-ness of defining Force-Authenticate, but that's just an aesthetic 
opinion.

Lisa

On Oct 29, 2005, at 5:45 AM, Geoffrey M Clemm wrote:

>
> I agree that LOCK is the real answer here for WebDAV clients.
>
> But for the "force-authenticate" advocates (which Julian is not):
> If we are contrasting "Expect 100-Continue" vs. "force-authenticate",
> I think it would make more sense to advise servers to implement Expect
> correctly rather than to introduce a new force-authenticate header.
> In particular, why would one believe that a server that doesn't 
> implement
> Expect properly would implement force-authenticate properly (or at 
> all).
>
> Cheers,
> Geoff
>
> Julian wrote on 10/29/2005 04:20:45 AM:
>  >
>  > 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?
>  >
>  > It could, but it's a known problem that few servers implement that
>  > correctly, meaning that the expected header check is indeed skipped 
> (for
>  > instance, a server using the servlet API normally doesn't have any
>  > chance doing this check, see
>  > <http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4812000>).
>  >
>  > > 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?  
>  >
>  > Seems so, because LOCK seems to be yet another existing way to get 
> what
>  > those clients want.
>  >
>  > Best regards, Julian
>  >