CGI, multiple page data input.

[Justin C]

All of my web stuff (inhouse) until now has passed previously input data
back to the browser in hidden form fields when more data needs to be
collected. For example, my script that calculates shipping rates for
customer orders collects weight, number of items, country of destination
on the first page. When this page is submitted a new page is returned
asking for the dimensions of each box, this second page form is
dependent on input from the first page (each box can be different
dimensions), but I also need some of the original page's input for my
calculations later, so the original data is passed back in hidden form
fields.

I'd like to move my coding forward a little and find a better way. I'm
guessing the cookies is the correct way to progress with this, but I
want to be sure, or hear of other ways before I commit to a cookies
approach for my new web-page.

Any suggestions of reading matter, or other ways of doing this, ... am I
barking up the wrong tree? Or just barking?!

Thanks for your suggestions.

Justin.

 

[Mathematisch]

Any suggestions of reading matter, or other ways of doing this, ... am I
barking up the wrong tree? Or just barking?!

Try using: CGI::Session

Regards, F

 

[Jürgen Exner]

All of my web stuff (inhouse) until now has passed previously input data
back to the browser in hidden form fields when more data needs to be
collected. For example, my script that calculates shipping rates for
customer orders collects weight, number of items, country of destination
on the first page. When this page is submitted a new page is returned
asking for the dimensions of each box, this second page form is
dependent on input from the first page (each box can be different
dimensions), but I also need some of the original page's input for my
calculations later, so the original data is passed back in hidden form
fields.

I'd like to move my coding forward a little and find a better way. I'm
guessing the cookies is the correct way to progress with this, but I
want to be sure, or hear of other ways before I commit to a cookies
approach for my new web-page.

You are looking for sessions.

Of course this has nothing to do with Perl whatsoever because the
concept of sessions is totally independent of whatever programming
language you happen to be using to implement them.

jue

 

[Xho Jingleheimerschmidt]

All of my web stuff (inhouse) until now has passed previously input data
back to the browser in hidden form fields when more data needs to be
collected. For example, my script that calculates shipping rates for
customer orders collects weight, number of items, country of destination
on the first page. When this page is submitted a new page is returned
asking for the dimensions of each box, this second page form is
dependent on input from the first page (each box can be different
dimensions), but I also need some of the original page's input for my
calculations later, so the original data is passed back in hidden form
fields.

As long as the data is not meaningfully subject to falsification, or is
revalidated at each stage, this is quite fine.

I'd like to move my coding forward a little and find a better way. I'm
guessing the cookies is the correct way to progress with this, but I
want to be sure, or hear of other ways before I commit to a cookies
approach for my new web-page.

It is not clear to me that the direction you indicate is a 'forward'
direction.

Xho

 

[Justin C]

Try using: CGI::Session

Thank you. I have the documentation for this open and it looks
interesting. It looks like a whole new can of worms compared with my
very basic web programming.

Justin.

 

[Justin C]

You are looking for sessions.

Yes, I see that now.

Of course this has nothing to do with Perl whatsoever because the
concept of sessions is totally independent of whatever programming
language you happen to be using to implement them.

ISWYM... now I know what it is that that I'm asking!

Justin.

 

[Justin C]

Yes, I see that now.

Jurgen, I did mean to say thank you at this point, it was not my
intention to be as rude as the above looks. Sorry, and thank you for
your suggestion.

Justin.

 

[Justin C]

As long as the data is not meaningfully subject to falsification, or is
revalidated at each stage, this is quite fine.


It is not clear to me that the direction you indicate is a 'forward'
direction.

Xho, the problem is that in some of my programs there are many fields to
the forms (invoice lines, often they number in the hundreds), and to
add:
print hidden(-name=>'some-name', -value=>$cgi->param('some-name'));
a few hundred times is extremely ugly. There has to be a better way. But
as Jurgen mentioned, it's not a perl problem, though it can be solved
with perl.

I've looked at CGI::Session, and decided to re-invent the wheel. The
program is for internal use only and there is nothing to be gained by
users messing around with it, so I'm creating a sort of session ID that
I will pass in a hidden field, and using Storable to store/retrieve the
entire hash submitted by the browser. CGI::Session seemed overkill.

For a session ID I'm using:
my $sid = md5_hex (int(rand(99999999)));

and also using that as a file-name to store the data between http
submissions.

Thanks to all for the suggestions, they've got me to a solution to the
problem that is rather simple. I guess that I will have to learn about
real sessions should I ever make something like this available to the
world.

Justin.

 

[Xho Jingleheimerschmidt]

Xho, the problem is that in some of my programs there are many fields to
the forms (invoice lines, often they number in the hundreds), and to
add:
print hidden(-name=>'some-name', -value=>$cgi->param('some-name'));
a few hundred times is extremely ugly.

Well then don't do that. Use a loop. Switching from hidden to session
isn't going to change that. You can write horrible code either way, if
you work hard at it.

And where do these hundreds of invoice lines come from? Did you make
the user enter them one by one, each into a different form element? Or
did you compute them from a more compact form of entry? If the latter,
why not just send back the compact form, and recompute the list on the
next submission?

There has to be a better way. But
as Jurgen mentioned, it's not a perl problem, though it can be solved
with perl.

I've looked at CGI::Session, and decided to re-invent the wheel.
Why?


The
program is for internal use only and there is nothing to be gained by
users messing around with it, so I'm creating a sort of session ID that
I will pass in a hidden field, and using Storable to store/retrieve the
entire hash submitted by the browser. CGI::Session seemed overkill.

For a session ID I'm using:
my $sid = md5_hex (int(rand(99999999)));

Why not just use the random integer directly? Using md5 this way
doesn't make accidental collisions less likely. And since you have just
published your intentions, using an md5 doesn't make malicious ones less
likely, either.

Xho

 

[Justin C]

Well then don't do that. Use a loop. Switching from hidden to session
isn't going to change that. You can write horrible code either way, if
you work hard at it.

Oh, I don't have to work hard, it comes perfectly naturally. I am,
however, trying to improve.

And where do these hundreds of invoice lines come from? Did you make
the user enter them one by one, each into a different form element? Or
did you compute them from a more compact form of entry? If the latter,
why not just send back the compact form, and recompute the list on the
next submission?

The user copy/pastes. That is an idea, I shall think about it.

Why?

I know, makes no sense, call it a logic failure. Either I get the hang
of sessions or I don't, what I have proposed appears to fall between the
two, yes it is some kind of session management, but it isn't as robust
as 'real' session management as provided by CGI::Session.

Maybe time to think again.

Why not just use the random integer directly?

Because I stupidly swiped the code from a web-site somewhere and gave no
consideration to why they were doing it that way... I still have no
idea.

Using md5 this way
doesn't make accidental collisions less likely. And since you have just
published your intentions, using an md5 doesn't make malicious ones less
likely, either.

This is purely for internal use at my employment, and I don't think
there is any way a user here could maliciously use previously uploaded
invoice data to create an invoice for customs. If they wanted to create
a false invoice it's easier to just provide the false data in the first
place.

Thank you for pointing out the errors in my thinking (or errors I make
when I don't think).

Justin.