Re: receipt of form values by an HTML page

Scott Bryce <sbryce@xxxxxxxxxxxxxx> writes:
Chris Morris wrote:
You then don't have to validate anything other than the new data and a
single quick test for all the old data.

And you still need a way to handle a situation where the data from the
first form comes back different from the second form.

Reject it outright, in that case; throw up an appropriate 40x
page. There's a difference between failing a validation check due to
user error (putting 15 instead of 1.5 in a field taking values from 0
to 10) and failing a validation check due to suspiciousness
(user-opaque hidden field gets edited)

Your method is better than putting the data from the first from into
hidden fields with no way of knowing if the data had changed with the
submission of the second form. I would still prefer storing the data
from the first form on the server.

You still need to store a pointer to the data on the client and have a
way to validate that, though. That is an even easier problem, of
course. I'd be inclined to store that pointer in a hidden field rather
than a cookie, too, since it makes XSRF harder.

I'd generally prefer to store temporary data in a multiple-stage form
on the client: less load on the database (if indeed there's a database
available at all), and no need to make decisions about how long a
session lasts before you clean up the server-stored data. Depends on
the form, of course, and even with client storage it's nice to provide
a way for them to save their progress and close the browser if they
need to.

--
Chris
.