Hi Gabor, Yes indeed, safer and … simpler (a lot simpler). Also, the “place holder” in the imported string doesn’t have to be a variable name. Good for maintenance!
Thanks! Meir From: Perl [mailto:[email protected]] On Behalf Of Gabor Szabo Sent: יום ה 31 יולי 2014 22:40 To: Perl in Israel Subject: Re: [Israel.pm] Not understood behavior of 'eval' So if I understand you have SQL snippets read from some external source where sometimes there are tags that look like perl scalars e.g. $date that need to be replaced by the value in the variable $date. This sounds like a simple template system where the template tags look like perl scalars. Using substitution instead of eval sounds safer. if you get a string $str = 'WHERE date = $date' you could replace it by $str =~ s/\$date/$date/g; While you are still exposed to SQL injection, at least you are not exposed to reading in something like $str = 'system "rm -rf /" ' eval-ing that the only protection you have is that Windows does not have an rm command. Gabor On Thu, Jul 31, 2014 at 8:31 PM, Meir Guttman <[email protected]> wrote: Yes indeed! Some bits and pieces are taken from an INI file, some from the user’s input. Elements include table names, column names, and may be an arbitrarily structured (but legal) WHERE clause which might include some variable names such as that date. Meir From: Perl [mailto:[email protected]] On Behalf Of Gabor Szabo Sent: יום ה 31 יולי 2014 19:41 To: Perl in Israel Subject: Re: [Israel.pm] Not understood behavior of 'eval' Do I understand you correctly that you are trying to build and SQL statement on the fly? Something like this? my $sql = 'SELECT * FROM costumers WHERE'; my @params; if ($day eq 'Sunday') { $sql .= ' date = ? '; push @params, $date; } .... $sth = $dbh->prepare($sql); $sth->execute(@params); Could you give a bit more context? regards Gabor
_______________________________________________ Perl mailing list [email protected] http://mail.perl.org.il/mailman/listinfo/perl
