Re: User confirmation and 307 redirects

On Thu, Aug 19, 2010 at 4:21 PM, Roy T. Fielding <fielding@gbiv.com> wrote:
> On Aug 19, 2010, at 3:44 PM, Adam Barth wrote:
>
>> On Thu, Aug 19, 2010 at 3:37 PM, Roy T. Fielding <fielding@gbiv.com> wrote:
>>> On Aug 19, 2010, at 3:20 PM, Adam Barth wrote:
>>>> If you think that 307 redirects are a security vulnerability, then
>>>> should should remove them from the protocol.  Trying to atone for the
>>>> security sins of the protocol by punting security to the user is
>>>> security theater.
>>>
>>> Using the Internet is a security vulnerability, yet there are sufficient
>>> trade-offs to justify it.   The same goes for redirecting an unsafe
>>> method if and only if the redirection has been preconfigured or
>>> acknowledged by the user.  How that is arranged is not defined by
>>> the protocol -- it is left up to the user agent developer to decide
>>> on their own user interface *if* they want to autoredirect an unsafe
>>> method.
>>
>> The draft says:
>>
>> [[
>>  Otherwise, the user agent MUST NOT automatically
>>  redirect the request unless it can be confirmed by the user
>> ]]
>>
>> If the user agent developer can choose whether or not to autoredirect
>> an unsafe method, in what sense is this requirement a MUST NOT?
>
> The user interface for obtaining confirmation is designed by the
> user agent developer.  The user agent developer can choose to never
> automatically redirect, provide some form of whitelist or zone
> functionality that preapproves such an automated redirect, or
> obtain a confirmation directly from the user upon receipt of
> the redirect -- any one of those satisfies the HTTP requirement.
>

If the user agent developer can choose to whitelist some redirects,
doesn't that directly contradict the text?

Also, suggesting that the "user" is the designer of the UI (or the
programmer), and not the viewer or the end-user, would seem to
contradict common usage in our specs.

-- Dirk

Received on Thursday, 19 August 2010 23:40:10 UTC