[159769] in North American Network Operators' Group
Re: Suggestions for the future on your web site: (was cookies, and
daemon@ATHENA.MIT.EDU (oscar.vives@gmail.com)
Mon Jan 21 03:27:12 2013
In-Reply-To: <20130121061926.GS31028@hezmatt.org>
From: " ." <oscar.vives@gmail.com>
Date: Mon, 21 Jan 2013 09:26:40 +0100
To: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On 21 January 2013 07:19, Matt Palmer <mpalmer@hezmatt.org> wrote:
...
>> If the form is submitted without the correct POST value, if their IP
>> address changed, or after too many seconds since the timestamp,
>> then redisplay the form to the user, with a request for them to
>> visually inspect and confirm the submission.
>
> Which is decidedly more user-friendly than most people implement, but
> suffers from the problem that some subset of your userbase is going to be
> using a connection that doesn't have a stable IP address, and it won't ta=
ke
> too many random "please re-confirm the form submission you made" requests
> before the user gives your site the finger and goes to find something bet=
ter
> to do.
>
You want to stop the CSRF problem, but you want to support a user
making the login in a IP, and submiting a "delete account" button *the
next second* from a different IP. then you want this solution to be
better cost effective than cookies.
Maybe ask the user his password.
<form method=3D"post">
<input type=3D"hidden" name=3D"id_user" value=3D"33">
<input type=3D"hidden" name=3D"action" value=3D"delete_user">
<input type=3D"submit" value=3D"Delete user">
<p>For this action you must provide the password. </p>
<input type=3D"password" name=3D"password" value=3D"">
</from>
Even if this request come from a IP in china, you can allow it.
--
--
=E2=84=B1in del =E2=84=B3ensaje.
