in reply to CGI: Make one big program or lots of little ones?

I find that its much easier to use a single script split up into subs. Its fairly easy to invoke the subs by setting a variable to do so in the form you are submitting: 
...
<input type="hidden" name="op" value="some_operation">
...

[download]
and in your script, you'll want to do something like this 
... #(generic code / beginning of HTML dumped here)

&$op();

... #(generic code / end of HTML dumped here)

[download]
of course, its possible that someone playing with your form could execute subs that you'd rather they not, so I suggest creating an array, with the names of subs that are "safe" to run: example: 
@safesubs = ("this_sub", "that_sub", "other_sub");
$ok = 0; #op is not okay to run until we say so ;-)
foreach (@safesubs) {
    if($op eq $_) {
        $ok = 1; #if the op is safe, set $ok to true
    }
}

if($ok) {
    &$op();
} else {
    die("The op variable does not contain a valid definition");
}

[download]
Or something along those lines. I hold the mindset that a CGI is responsible for accomplishing a certain task, such as dealing with user administration, for instance. That one script should allow me to add, edit, and/or delete users at whim, without calling on other scripts to do the job. Besides, it keeps your cgi-bin a lot cleaner ;-)

I've never claimed to be a Perl God(TM), and any claims to the converse are used fictitiously.

Replies are listed 'Best First'.
Re: Re: CGI: Make one big program or lots of little ones?
by tomhukins (Curate) on Feb 22, 2001 at 18:43 UTC
    This is a technique that I use, either using hidden fields as you describe or passing flags in PATH_INFO.

    However, I would use a hash instead of your @safesubs and $ok: 

    my %valid = map {$_ => undef} qw(this_sub that_sub other_sub);
die unless exists $valid{$op};
&$op();

    [download]
[reply]
[d/l]
      Well passing flags in the PATH_INFO works fine, but wouldn't encourage doing it that way, beacause the browser will show the whole path (including flags). This is fine if there is no real sensitive info in the path, but it can be more of a security risk. Using hidden fields is a bit safer.
      But your code itself does look a lot nicer ;-)

      I've never claimed to be a Perl God(TM), and any claims to the converse are used fictitiously.
[reply]

        Whether the programmer is using hidden fields or PATH_INFO, it's important to check all user-supplied data on the server side.

        Server side validation is essential for all Web development where untrusted users might access your site. Reference: The WWW Security FAQ.

[reply]

In Section Seekers of Perl Wisdom