in reply to Variable variable names

At the risk of presenting heresy, (and after reading all 3 of the "use soft references and die!" articles) I'd like to say that I like using soft references when I'm writing CGIs.

Here's the deal: When you're writing a CGI, you know (well, most of the time) all the form element names. Lots of times there's lots of elements, and for security's sake you only want to mess around with the elements that you care about. (i.e., if some bozo submits a form element named "foo" you want to ignore it and not import it accidentally into your namespace.) So, here's a favorite idiom I like to use: 

@vars = qw(name rank serial_num shoe_size);
foreach (@vars) {
   ${$_} = param ($_};
}

[download]
...and that's it. Now I have magically created a batch of globals that I want... that I know I want, while properly ignoring anything extraneous that the form might be handing my CGI. Because it's a CGI, it is very unlikely that I'll want to use a "$name" variable somewhere else for some purpose other than sucking in the "name" element as in my example. (After all, it's easy to keep track of "form element = variable name") Plus, as I add (or subtract) values from my HTML form all I have to do is add (or subtract) elements from my @vars array.

Now, according to the (excellent) articles I should not use soft references but instead do something like this: 

@vars = qw(name rank serial_num shoe_size);
foreach (@vars) {
   $form_input{$_} = param ($_};
}

[download]
...but I mean, really, isn't that almost the same thing? The only thing this buys you is a (fractionally) smaller percentage of accidentally blowing one of your variables away, something that's even less likely to happen when you localize all your subs anyway.

Don't mean to be crazy here, but remember, variables don't kill people... people kill people.

Gary Blackburn
Trained Killer

Replies are listed 'Best First'.
RE: Re: Variable variable names
by btrott (Parson) on Oct 24, 2000 at 03:16 UTC
    Here's one of the summaries from the last of mjd's articles: 
        One of the biggest problems in all of compter
    programming is namespace management and data
    hiding. When you use a symbolic reference you are
    throwing away forty years of expensive lessons from
    the School of Hard Knocks.

    [download]
    The fact is, a hash in my opinion buys you much larger than a "fractional" benefit w/r/t blowing away your variables. Why do you want to mix up your form values with variables in your application? What are you *gaining* by doing that?

    You give the example of a variable called $name: 

        Because it's a CGI, it is very unlikely that I'll want
    to use a "$name" variable somewhere else for
    some purpose other than sucking in the "name"
    element as in my example.

    [download]
    Sorry, but $name isn't a very good example of an uncommon variable name. :) That's the sort of thing that could very easily get you in trouble if your programs start getting larger, or if you start doing development in a team environment, etc.

    The basic point here is: you're buying yourself nothing, save typing a couple of characters, by not using a hash. Even if you view using a hash as providing only "fractionally" more security, why not use it?

[reply]
[d/l]
[select]
      All good points, but remember that it's a CGI, which means I am (by definition) stuck with that pesky HTML form and those form elements. I want to confuse my element names with my application variables... one way of looking at it is a deliberate, controlled extension of my application's namespace to include the HTML form.

      I'm not saying that using a hash is a bad idea, but I do think that we should be very careful in our choice of dogma. Perl, far more than most languages, is not a black and white affair. I challenge the dogma that "all soft references are bad" by presenting a reasonable situation where some programmer somewhere might choose to use them to advantage.

      Gary Blackburn
      Trained Killer

[reply]
        I want to confuse my element names with my application variables... one way of looking at it is a deliberate, controlled extension of my application's namespace to include the HTML form.
        And the day someone returns a form variable that happens to overwrite your value of $authorized with 1 for a critical application, you are toast. This already generated a CERT warning for a PHP application... why repeat history with Perl when it is so easily avoided?

        In the security biz, we repeat two mantra:

        • Do not let your data become code.
        • Do not let your code become data.
        The wise one pays attention to both, with rigor.

        -- Randal L. Schwartz, Perl hacker

[reply]
RE: Re: Variable variable names
by chromatic (Archbishop) on Oct 24, 2000 at 08:15 UTC
    You seem to be a good enough programmer that you can probably get away with symbolic references in this case. (I tend to use the list of allowed variables too.)

    I don't like the idea of encouraging beginning programmers to use them, however. It's a quick way to open up a security hole in a CGI script, and you don't get the protection of -w and strict. Worst yet, it lets beginning programmers tie themselves up in knots trying to make "var1", "var2", ... "varn" when they should be using an array or a hash.

    Programming well is hard enough without encouraging people to put on blindfolds, put raw meat down their pants, and dangle over an alligator pit. People like you and I, who know what we're doing (or can fake it convincingly) can get away with that sort of thing... but I'm not going to recommend it for someone who can't tell me what a typeglob is, for example.

[reply]

In Section Seekers of Perl Wisdom