receipt of form values by an HTML page

**Steve Swift** · Oct 11 '07, 10:55 AM

Re: receipt of form values by an HTML page

If I could collect the form values from the first HTML page and pass

them to the second HTML page, I could go home early and watch the ball
game. Is there anyway to do this? Example below.

Well, this is how I'd do it:

I'd modify your existing page to become page 1 and have it submit its
POST data to a new CGI script. If you can fiddle your server so that
requests for the initial page get redirected to this script then so much
the better, because the script that handles Page1 data might have to
redisplay page1 with error messages. It might as well handle GET
requests by displaying the initial page, then everything comes together
in one script.

Your new script validates Page1 data when POSTed and either rewrites
Page1 if the data has errors or writes page2, with the page1 data in
hidden fields, and the page 2 fields in the same form.

I'd have page2 drive the same (new) script again, as I find it easier to
keep everything in one script, but you could have a separate script to
handle page2.

I do this sort of thing all the time. (Inside my employer's private
network). I have sequences of several pages that gather data in stages,
carrying it forward in hidden fields. It's precisely what hidden fields
were designed for.

The prior poster seems to have some concerns that the hidden fields from
page 2 (which are actually the page1 data) may not come through
correctly, but anyone who could subvert these fields could do the same
to your original HTML form, so I don't see any new hazard.

--
Steve Swift

404 - Page not found - Swiftys

http://www.swiftys.org.uk/swifty.html

http://www.ringers.org.uk

**Scott Bryce** · Oct 11 '07, 02:55 PM

Re: receipt of form values by an HTML page

Steve Swift wrote:

The prior poster seems to have some concerns that the hidden fields from
page 2 (which are actually the page1 data) may not come through
correctly, but anyone who could subvert these fields could do the same
to your original HTML form, so I don't see any new hazard.

It isn't a new hazard. The OP has to be aware that after receiving those
values back in hidden fields in the second form, the hazard exists a
second time. He can't assume that because he validated them once, they
are still good.

**Chris Morris** · Oct 11 '07, 03:25 PM

Re: receipt of form values by an HTML page

Scott Bryce <sbryce@scottbr yce.comwrites:

Steve Swift wrote:

The prior poster seems to have some concerns that the hidden fields
from page 2 (which are actually the page1 data) may not come
through correctly, but anyone who could subvert these fields could
do the same to your original HTML form, so I don't see any new
hazard.

>
It isn't a new hazard. The OP has to be aware that after receiving
those values back in hidden fields in the second form, the hazard
exists a second time. He can't assume that because he validated them
once, they are still good.

However, by storing the data correctly in the hidden fields, you can
avoid having to revalidate it:
- serialise all the data you would put into the hidden
fields into a single string.
- one-way hash the data (e.g. sha1) with a secret salt.
- place the serialised data into a hidden field, and the hash into another.
(or add it on to the end of the serialised data in the same field)
- when the form is submitted, recalculate the hash, and if it
matches, unserialise the data (which you know is unchanged). If it doesn't
match, reject the submission.

You then don't have to validate anything other than the new data and a
single quick test for all the old data.

--
Chris

**Scott Bryce** · Oct 11 '07, 03:45 PM

Re: receipt of form values by an HTML page

Chris Morris wrote:

However, by storing the data correctly in the hidden fields, you can
avoid having to revalidate it:

Not really.

- serialise all the data you would put into the hidden
fields into a single string.
- one-way hash the data (e.g. sha1) with a secret salt.
- place the serialised data into a hidden field, and the hash into another.
(or add it on to the end of the serialised data in the same field)
- when the form is submitted, recalculate the hash, and if it
matches, unserialise the data (which you know is unchanged). If it doesn't
match, reject the submission.

Which amounts to revalidating the data, albeit in a different manner.

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.

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.

**Chris Morris** · Oct 11 '07, 03:55 PM

Re: receipt of form values by an HTML page

Scott Bryce <sbryce@scottbr yce.comwrites:

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

**cartercc@gmail.com** · Oct 11 '07, 08:05 PM

Re: receipt of form values by an HTML page

Thank you all very much. I've decided to bite the bullet and spend a
day recoding the app. This is what I'm going to do:

1. Collect the info from the first (new) HTML page and send it to the
CGI script.
2. Read the values into variables (not hidden from controls) to a new
CGI script, which will collect the remainder of the info.
3. From there, continue with the app as it exists.

I was trying to avoid rewriting the HTML form but it doesn't seem to
be possible. At least I can start by incorporating the relevant
portions as a heredoc in the new CGI script.

Thanks, all, CC

**Scott Bryce** · Oct 12 '07, 04:15 PM

Re: receipt of form values by an HTML page

cartercc@gmail. com wrote:

I tend to stuff common code
in a library module and use a lot of heredocs. That way, HTML is HTML,
code is code, and (almost) everything is DRY. Personally, I do not
like to mix code and HTML

But that is my point. By stuffing the HTML into heredocs, you are mixing
HTML and code.

The HTML::Template module will allow you to put the HTML in a separate
file. Your code will only have to "fill in the blanks" by supplying the
values to be inserted into the template.

Trust me. It is a much better way to do CGI. At least read the docs.
Then you can do whatever you want.

receipt of form values by an HTML page

receipt of form values by an HTML page

Comment

Comment

Comment

Comment

Comment

Comment

Comment