471,599 Members | 1,096 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,599 software developers and data experts.

receipt of form values by an HTML page

I think I already know the answer to this one, but I'm giving it the
old college try.

My problem is this: I have an HTML form that sends a bunch of data to
a Perl script, where it is validated and read into a database. The
powers that be have decided in their infinite wisdom that the initial
page needs to be broken into two parts. (This is an attempt to correct
some common user errors, not because of any technical reasons.) So I'm
sitting here looking at revising a mess of script, insert queries,
etc.

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.

Thanks, CC.

------here's what I would like to do---------------
PAGE 1:
<html>
<body>
<form name="form1" action="page2.html">
What is your name: <input type="text" name="name" />
<input type="submit" value="Go to page 2" />
</form>
</body>
</html>

PAGE 2:
<html>
<body>
<!-- get name from page1 somehow -->
<form name="form2" action="cgi-bin/page3.pl">
What is your class: <input type="text" name="class" />
<!-- perhaps something like?
<input type="hidden" name="name" value="name-from-page-1" -->
<input type="submit" value="Go to page 3" />
</form>
</body>
</html>

Oct 10 '07 #1
7 4160
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
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk
Oct 11 '07 #2
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.
Oct 11 '07 #3
Scott Bryce <sb****@scottbryce.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
Oct 11 '07 #4
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.
Oct 11 '07 #5
Scott Bryce <sb****@scottbryce.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
Oct 11 '07 #6
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
Oct 11 '07 #7
ca******@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.
Oct 12 '07 #8

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

5 posts views Thread by Chris Thunell | last post: by
1 post views Thread by hasanainf | last post: by
4 posts views Thread by Cerebral Believer | last post: by
26 posts views Thread by Jerim79 | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.