http://qs321.pair.com?node_id=383250

blazesixty has asked for the wisdom of the Perl Monks concerning the following question:

Hail all perl masters!

I come for wisdom, simple one it may be to you, but a tremendous help to me.

I need to write a few perl scripts to generate html pages for E-commerce processing purposes. The procedure would go as follows :

User hits order-now link and it brings up a html page with the usual order form fields (name, adress) yada yada.

I would like the Post target for the form to be a clever perl script that does the following:

* Validates user input, if incorrect, posts back with red asterisks, and prompts for user input fixation.

* If input is correct, script calculates cost of order and generates a new HTML page, the new HTML page will have all the values listed in the previous HTML page, but with the calculated costs etc. This page will post to the merchant account gateway.

Thats it! That is all I need. I need some guidance, but not something too overwhelming. I have joined some perl IRC channels, and there all I get is "check out perldoc.com"

Some examples of existing work would do wonders for me. I am positive you guys have done something like this before!

20040816 Edit by ysth: change title from: Perl newbie

  • Comment on How do I write a CGI script with form validation?

Replies are listed 'Best First'.
Re: How do I write a CGI script with form validation?
by nothingmuch (Priest) on Aug 16, 2004 at 10:58 UTC
    Ovid, a very valuable monk here at perlmonks wrote a very nice, intro level cgi course. You should have a look.

    More specifically, you read about the CGI module, some templating solution like HTML::Template (or Petal, my favorite), and maybe even an all dancing wonder framework, such as Maypole or it's competitorrs.

    Good luck!

    Update: fixed some really lousy english.

    -nuffin
    zz zZ Z Z #!perl
Re: How do I write a CGI script with form validation?
by bgreenlee (Friar) on Aug 16, 2004 at 11:18 UTC

    In addition to ovid's tutorial already mentioned, here are a few more links for you to check out:
    Perl CGI Tutorial
    Beginner's Guide to CGI Scripting with Perl

    Also, you'll need to pay close attention to security if this is for an ecommerce app. E.g. don't trust that the order total passed to you in a POST is right, as it's easy for an evildoer to make up their own price and bypass your validation. One way around this is to store sensitive data on the server, and reference it via a session id, which gets passed via POST or GET. Have a look at Apache::Session. You can also validate data being passed to you by including an MD5 (or SHA) hash of the values plus some secret key.

    -b

Re: How do I write a CGI script with form validation?
by matthewb (Curate) on Aug 16, 2004 at 11:53 UTC

    The difference between Perl newbie and making a living is realising that there is no good reason to be trying to program a form validator. This is a problem that has long-since been solved.

    CGI::Application::ValidateRM is an easy to use software library that marries the structure enforcement of CGI::Application with the pre-built form validation capabilities of Data::FormValidator in a useful and stylish way.

    While it may not be immediately obvious how to set this solution up, the time you invest in finding out will likely be more profitable to you than trying to work out a comparable solution yourself. It will also teach you more about building software. You can bring specific problems back here for expert advice.

    Personally, I stick a bit of Javascript validation on my forms in addition to this since it can save the end user a page refresh but that's a matter of personal taste.

    MB
Re: How do I write a CGI script with form validation?
by Gilimanjaro (Hermit) on Aug 16, 2004 at 11:32 UTC
    For eCommerce applications I would definitely use sessions to store the state of the transaction. Whether you pass the session id using a http parameters or a cookie depends on whether you will be in a position to 'demand' site-compliance from your customers.

    Furthermore, especially when forced to use plain cgi, I like to separate the entry, validation and processing into separate scripts with their respective templates. The validation script I usually create has no output of it's own, but redirects to either the form page (in case of problems) or the processing page (it it's all ok) after setting the appropriate 'validated' flag in the user's session store...

    I would definitely read up on the HTTP protocol, and more specifically on GET/POST parameters and Cookies so you get more of a feel for the issues you'll be dealing with.

    I wouldn't rely on JavaScript for validation, as users may have it disabled, and more importantly developing multi-browser compatible JavaScript is an art on it's own. If you do decide to use it, I'd try to find prefab snippets for your purpose, and I'd still do server-side validation for security reasons.

Re: How do I write a CGI script with form validation?
by rhythmicus (Sexton) on Aug 16, 2004 at 11:20 UTC

    Without knowing all the details, I'd say your best bet would be to validate the user input via JavaScript. Since JavaScript is client-side, you won't need to send the user input to the server and then back again if it's incorrect.

    As for outputting the results of your calculations, etc., you can do this the simple way with CGI, or the slightly more complicated way, although with more control and cleaner code, with HTML::Template.

    This kind of stuff is very common. Search this site and Google for more information.

    UPDATE: As some other monks have caught a mistake in my original post, I should add that I neglected to mention that user input should ALSO be checked at the server-side. However, contrary to what tachyon says, I do believe that JavaScript provides additional security and does have some degree of reliability.

    UPDATE Part II: For a good example of using JavaScript to help validate input, check out http://developer.apple.com/internet/webcontent/validation.html.

      I'd say your best bet would be to validate the user input via JavaScript

      Bad advice. Client side validation is fine, provided you accept that it is simply to improve the end user experience. It offers absolutely no security or reliable validation

      Form validation is a server side task. Period. Do what you like on the client side, you still need to validate everything (again if using JS client side) on the server side.

      cheers

      tachyon

      I beg to differ.

      You cannot allow the server to trust that the client side is not tricking it, especially for ecommerce.

      All form validation must happen at the server, and possibly, for a better user experience (think responsiveness), also validated with javascript.

      I'd also like to note that inn my experience most the javascript validation I met really sucks. Just recently I had to fool an online purchase form which was trying to verify my CCN using javascript that calls a VB script function. I have MacOS X, and use Safari, which isn't VB script enabled.

      The only way I could actually buy the thing is if i cheated the javascript. It was simple, too, i just entered the URL javascript:document.formname.submit().

      -nuffin
      zz zZ Z Z #!perl

      I *used* to do form validation with javascript exclusively, until lurking around the monastery for a few months and reading the arguments against it, and for good reasons. However, I now use a combo. I do a full validation (as part of my untainting routines) on the server-side, but first doing a quick check of certain fields in javascript to avoid the roundtrips to the server. The client-side checks are more to protect the "client" and the server-side check are to protect me and the server.

      As my validation needs are pretty straight forward, I rolled my own little module with the help of some of the good monks, and it works fine. But do recommend you read up on the aforementioned CGI resources.


      —Brad
      "Don't ever take a fence down until you know the reason it was put up." G. K. Chesterton