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 15:15:52 UTC