Re: Interop issue: how can clients force authentication?

What we do is to send the authentication challenge for any method other than
GET or HEAD or OPTIONS.  I recall from the interop event that a number of
other servers did the same thing.

Most clients issue a LOCK or PROPFIND first and avoid this problem, but
perhaps this could be spelled out in the spec.

--Eric

----- Original Message -----
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Ilya Kirnos" <ilya.kirnos@oracle.com>; "Webdav WG"
<w3c-dist-auth@w3c.org>
Sent: Tuesday, September 17, 2002 12:46 PM
Subject: RE: Interop issue: how can clients force authentication?


>
> Some thoughts....
>
> 1) Do we really have an interop issue at all? From what I hear, it's
> considered a problem that when submitting a large PUT, you may not hear
> about the 401 before you have sent the whole request. So that's "just" a
> performance issue (actually, a known one).
>
> 2) If there *would be* consensus that we need this kind of
> you-wikll-have-to-authenticate-for-PUT signalling, I'd propose to make
this
> a live property. Just issue a PROPFIND on it in case you want to know. No
> new request header (-> HTTP header namespace unaffected), no new OPTIONS
> semantics, no new compliance class.
>
> 3) Finally -- we should be looking for *existing* ways to solve this
problem
> for RFC2518bis. For instance:
>
> 3a) Try a PROPPATCH first -- if you can't change the metadata, it's likely
> that you won't be able to change the content either.
>
> 3b) Try a zero-length PUT first.
>
> 3c) Try a LOCK first.
>
> 3d) Try a PUT with known-to-fail If header first (-> Stefan's proposal).
>
> ..and so on.
>
>
> Julian
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
> > -----Original Message-----
> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Ilya Kirnos
> > Sent: Tuesday, September 17, 2002 9:18 PM
> > To: Roy T. Fielding
> > Cc: Webdav WG
> > Subject: Re: Interop issue: how can clients force authentication?
> >
> >
> >
> >
> > "Roy T. Fielding" wrote:
> >
> > > Authorization is granted/denied based on the method of the request.
> > > There might even be different challenges per method.  In other words,
> > > this idea won't work for HTTP.
> > >
> >
> > right, i was hoping to finesse the issue by saying that if any
> > method needed
> > authentication, the server should challenge.  however, if
> > challenges differ
> > for different methods, then obviously this won't work.
> >
> > >
> > > The original idea of OPTIONS was that, if the client wished to test
the
> > > options for a specific request, then it would include that request's
> > > request-line and headers in the body of the OPTIONS request.  The
server
> > > would then look at the body to determine what the options would be and
> > > report that back to the client.  However, since the WG did not want to
> > > define the format of such a response, the feature got dropped.
> > >
> > > The alternative was to simply issue the request with Expect:
> > 100-continue.
> > >
> > > I don't know if that is sufficient for your problem, but I do know
that
> > > using a T/F request header field on OPTIONS is not.  A minimum would
be
> > > to list the methods in that field instead.  I also suggest finding a
> > > less verbose field name.
> > >
> >
> > sounds like an idea to me, but if in fact it is common for servers to
have
> > different challenges for different methods, then we have a whole
> > new set of
> > problems.  would the order of the list of methods determine which
> > challenge is
> > returned?  do clients have to issue this OPTIONS request for each new
> > operation they try to do (i.e., i sent a list that had PUT first
> > for my last
> > operation, but now i'm about to do a PROPPATCH -- do i have to
> > send a new list
> > that has PROPPATCH first?).
> >
> > perhaps in its response the server could return which methods the
> > challenge
> > would cover if successfully answered.  so the sequence would look like:
> >
> > request:
> >
> > OPTIONS /blah HTTP/1.1
> > Host: blah
> > Force-Authenticate: PUT, PROPPATCH, etc...
> >
> > response:
> >
> > HTTP/1.1 401 Unauthorized
> > WWW-Authenticate: ....
> > Authenticate-Methods: PUT, PROPPATCH, etc...
> >
> > and now the client can send a PUT, PROPPATCH, or etc... if it has
> > the right
> > credential for the challenge.
> >
> > From my experience with HTTP server configurations, most
> > challenges tend to
> > cover either all write methods or none (at least if the
> > configuration is done
> > properly), but this would leave the door open for those that do
something
> > different.
> >
> > -ilya
> >
> >
>
>

Received on Tuesday, 17 September 2002 20:31:53 UTC