Is there a better way of doing this?

[Bill H]

In a script I have on a site I read all the values passed in the url
(using the GET method) into an array called $query{'foo'} where foo is
the name of the value. Though this has always worked fine I find
myself assigning them to a new variable to make it easier to recognize
them and quicker to type, for example I'll make $foo = $query{'foo'};

The question is, is there anything wrong with doing the following to
automate this process, or is there a better "perl" way of doing the
same?


foreach $temp (keys(%query))
{
eval("\$$temp = \$query{\$temp};");
}

Bill H

 

[usenet]

In a script I have on a site I read all the values passed in the url
(using the GET method) into an array called $query{'foo'}

http://search.cpan.org/~lds/CGI.pm-3.29/CGI.pm#FETCHING_THE_PARAMETER_LIST_AS_A_HASH:

 

[Klaus]

[snip]

[rearranged from the bottom]

foreach $temp (keys(%query))
{
eval("\$$temp = \$query{\$temp};");
}

The question is, is there anything wrong with doing the following to
automate this process

String-eval is dangerous if you don't control the content of $temp and
it is also slow.

or is there a better "perl" way of doing the same?

You could try symbolic references (see perldoc perlref), but beware:
Only package variables (globals, even if localized) are visible to
symbolic references. Lexical variables (declared with my()) aren't in
a symbol table, and thus are invisible to this mechanism

 

[Paul Lalli]

In a script I have on a site I read all the values passed in the url
(using the GET method) into an array called $query{'foo'} where foo is
the name of the value. Though this has always worked fine I find
myself assigning them to a new variable to make it easier to recognize
them and quicker to type, for example I'll make $foo = $query{'foo'};

Why aren't you just using the standard CGI.pm module? Why are you
bothering to parse the query string and build a parameter list
yourself?

use CGI ':standard';
import_names 'Q';
print "Foo: $Q::foo\n";

Paul Lalli

 

[Jamie]

In a script I have on a site I read all the values passed in the url
(using the GET method) into an array called $query{'foo'} where foo is
the name of the value. Though this has always worked fine I find
myself assigning them to a new variable to make it easier to recognize
them and quicker to type, for example I'll make $foo = $query{'foo'};

The question is, is there anything wrong with doing the following to
automate this process, or is there a better "perl" way of doing the
same?


foreach $temp (keys(%query))
{
eval("\$$temp = \$query{\$temp};");
}

As everyone else has pointed out, someone could come along and pass in
whatever they want thus "surprising" you with new variables (or worse...)

You could, I suppose, mess around in the package symbol table if you wanted
to get around the eval part, thats what my example does.. but that makes for
some rather un-readable code.

If you're going to do it anyay, at least make sure you know which variables
your importing.


Not the "right" way to do it.. but at least it makes sure you're not throwing
in arbitrary variables or eval'd code:

---
use strict;
use vars qw($BAD $APPLE $Q);

# We're poking our nose into the main:: symbol table.
no strict 'refs';

# This is our "test" query, $BAD should NOT be tampered with.
my %query = (
APPLE => 'Rotten',
BAD => 'FAIL - Should NOT be set to this!',
Q => 'Keywords'
);

# This should be left ALONE!
$BAD = 'OK - not been messed with';

# Iterate through the variables we know are OK to mess with.
foreach my $vname (qw(APPLE Q)){
# Mess about with the symbol table of package 'main'
${'main::' . $vname} = $query{$vname};
}

# "prove" that $BAD wasn't touched.

print 'APPLE=',$APPLE,"\n",'Q=',$Q,"\n",'BAD=',$BAD,"\n";
---

You still need to be careful, GET is reasonably safe, but if someone posts in
HUGE chunks of data and you ever accept POST, you could be in for some nasties.

In general, it's better to use CGI::Simple or one of the other CGI-ish modules
for this. (it's also easier..)


Jamie

 

[Bill H]

The main thing wrong with this method is that you lose control of what
you are defining. You have no idea what is being passed to your
program. While you know what values a legitimate submission of your
form page will pass, there is nothing preventing a malicious person
submitting a totally bogus URL that could contain anything. What if I
submitted such a URL that defined an already-defined variable, thereby
clobbering or hijacking your CGI program.

There also doesn't seem to be much point. If you only use a value once,
then just use $query{'foo'} (or just $query{foo}). If you use it more
than once, put my $foo = $query{foo}. How many variables do you have
that you can't have one line defining scalar variables to use in the
rest of your program?

Jim

You have a good point there. The reason I want to use it is that I
have about 20 or so routines in a script that use various values
passed in the "get". But I never thought of someone just putting junk
in the line and causing problems so I may just do as you and Jamie
suggest: $foo = $query{'foo'};

This brings up another thing I have been working on. If you go on a
lot of sites they use what appears to be random characters on the url
but are infact the "get" data encoded. I have used this method before
where everything after the ? in the url is converted to hex so that it
isnt readable. Is there any perl routines that would encrypt this data
(or any string) and have some form of checksum in it? For example

Say my unencrypted line is: foo.pl?action=this&data=that

After encryption it would be something like: foo.pl?
kkiuKJHjy786jghjgjhERHGfgh

Then in my scrypt I would "decrypt" the text (held in the query line
of ENV) to get the original action=this&data=that which I would then
handle like a normal query line. Some form of checksum would be nice
so I could determine if the text had been mangled.

I could write this, but if there is a perl routine I would rather use
it.

Bill H