RE: Redirection of a POST as a GET

I agree ... that is perhaps a very well known special case which deserves
some form of distinguishing design ... perhaps a special redirect code
which would mean temporary change of security level for authentication.

In then end, I only want user choice required when they have a chance
of understanding the significance of the choice.

On Thu, 8 Mar 2007, Eric Lawrence wrote:

>
> << it seems VERY reasonable to not allow the
> scheme to change in a redirect ... certainly not a down grade in security
> level.>>
>
> Even here there's likely to be a problem.  A common pattern for web-based
> logins is to send credentials to a HTTPS page, and that returns a
> redirect with a Set-Cookie header containing an authenticated token.
> The redirected page is very often a HTTP page, and hence would trigger
> the warning in your model.
>
> -Eric
>
> -----Original Message-----
> From: ietf-http-wg-request@w3.org [mailto:ietf-http-wg-request@w3.org] On Behalf Of David Morris
> Sent: Thursday, March 08, 2007 1:12 PM
> To: Adrien de Croy
> Cc: ietf-http-wg@w3.org Group
> Subject: Re: Redirection of a POST as a GET
>
>
>
> If you have a trust relationship with the original server, you darn well
> better beable to trust what that server does with your data ... and in my
> mind, that extends to trusting that server to not redirect to an untrusted
> server.
>
> In any case, if this data is sensitive, you should make sure it is sent in
> an SSL protected session and it seems VERY reasonable to not allow the
> scheme to change in a redirect ... certainly not a down grade in security
> level.
>
> Telling the average user there is a concern isn't worth the effort.
^>

Received on Thursday, 8 March 2007 21:51:44 UTC