Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

davorg (18)

davorg
  dave@dave.org.uk
http://dave.org.uk/
Yahoo! ID: daveorguk (Add User, Send Message)

Hacker, author, trainer

Technorati Profile [technorati.com]

Journal of davorg (18)

Thursday September 05, 2002
09:42 AM

Being Too Clever

[ #7543 ]

Earlier this week I had an interesting problem. I had a web form that needed to pass data on to a third party CGI program (it's a credit card payment system). The inputs to the CGI program were defined by the company who own it and the web form inputs were defined by what the user would expect to see.

The two set of requirements did not match up.

For example, for repeating payments, the CC system wanted two separate values for amount and period. On the web form you only need one input for this as the amount paid is a function of how frequently you pay (you either pay £x a month or £12x a year).

So I needed to put an intermediate step in between the form and the CGI program. One that would calculate the amount given the period.

My first idea was quite simply brilliant (even if I do say so myself). I'd write my own CGI program which took the inputs, munged them around a bit and then made a POST to the external CGI program. My program would take the content returned by the external program, add a <base> tag and display it to the user. (Can you tell I've just read Perl & LWP?)

It all worked fine. Except for one thing. The external CGI program needs to set a cookie. And as it was my program that was actually doing the work, the external cookie didn't get a chance to set a cookie (or if it did, it set the cookie on the wrong domain).

I was just about to start writing code to get round this problem when someone pointed out a slightly "cheating", but far simpler solution - a confirmation page.

Now, my program munges the input parameters as appropriate, but instead of calling the external program, it simply displays a page that says "please confirm you want to make this payment". It displays all of their data back to them, but in the background all the real data is in hidden inputs. Submitting this form passes control over to the external CGI program.

It's probably an obviously solution to many of you reading this, but I just thought it was a useful reminder of the wisdom of keeping things simple :)

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Use of javascript (Score:3, Insightful)

    by 2shortplanks (968) on 2002.09.05 10:15 (#12530) Homepage Journal
    I've just being working on something similar. You know that you can assign a keyword to bookmarks in Google? And that if you put a '%s' in the url you can type 'keyword $string' into the url bar and have the url called with %s changed to a urlencoded version of $string.

    This works all very well until something needs a POST not a GET. So I have this script that takes any request and resubmits it to the defined url as a post:

    #!/usr/bin/perl

    # force as a hardcoded value for security reasons
    use constant URL => "http://theurlhere.com/cgi-bin/script.jsp";

    use CGI;
    my $q = CGI->new();

    # start the page
    print $q->header;
    print $q->start_html(-onLoad => "document.myform.submit()");
    print "Please wait...";

    # start the form
    print $q->start_form(-name   => "myform",
                         -action => URL);

    # print out all values
    foreach ($q->param())
    {
      print $q->hidden(-name  => $_,
                       -value => $q->param($_)) . "\n";
    }

    print $q->end_form;
    print $q->end_html;
    Now the important thing to note is that this script doesn't even have a submit button - as soon as the page is loaded javascript submits the page.

    Of course this will only work if you know they have javascript enabled (which in this case I do - it's my browser)

  • What's to stop somebody from editing the HTML page with the hidden variables before it gets submitted to the second CGI script? You'd need to do some kind of md5/sha1 checksum of the submitted data and validate it, surely?

    -Dom

    • Hmmm.... good point. This obviously isn't going to be quite as simple as I expected.

      • You only need security there if they can do anything bad with what they submit, ie generally if they can somehow change the price. Normally, they shouldn't be able to, you'd only send the ID of a product and how many of it they're taking and let the remote end do the math using prices in its store. Of course, it wouldn't be the first time I see an online sales system with that kind of hole...

        --

        -- Robin Berjon [berjon.com]

  • I haven't done much in the way of cookies, but conceptually they are sort of like a key=valkey=valkey=val hash, right? So, you get a cookie from the CC site on behalf of the user, and quote/escape/whatever to it, and set it as the value of one of those keys in a cookie you send to the user. Then, decode it when you get it back.

    Maybe. :)

    --
    J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers