Bareword errors?
gcr
Short version -
getting an inconsistant (?) bareword error
strict accepts the first use of the bareword(?) but not later -
(not under strict one runs - the other gives error.
Long version:
how come the first bareword at line 15 passes? - right under getweb()
---snip
Bareword "search2" not allowed while "strict subs" in use at ./s1why.cgi
line 19.
Bareword "search1" not allowed while "strict subs" in use at ./s1why.cgi
line 22.
Bareword "search2" not allowed while "strict subs" in use at ./s1why.cgi
line 22.
----snip
when 'strict' isn't used:
----snip
Can't locate object method "HASH" via package "search2" (perhaps you
forgot to load "search2"?) at ./s1why.cgi line 19.
I'll hack around this but curious why first use passes.
This is perl, v5.8.1-RC3 built for darwin-thread-multi-2level
os x 10.3.9
-----snip -----
#!/usr/bin/perl
use strict;
my $search;
my %HASH;
my $name;
my $value;
my @pairs;
my $buffer;
my $pair;
getweb();
if (!$HASH{search1}) {
$search = "search2 only";
}
if (!HASH{search2}) {
$search = "search1 only";
}
if (!HASH{search1} && !HASH{search2}){
$search = "no search";
}
sub getweb() {
if ($ENV{'REQUEST_METHOD'} eq 'GET')
{
@pairs = split(/&/, $ENV{'QUERY_STRING'});
}
elsif ($ENV{'REQUEST_METHOD'} eq 'POST')
{
read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
@pairs = split(/&/, $buffer);
}
foreach $pair (@pairs)
{
($name, $value) = split(/=/, $pair);
$name =~ tr/+/ /;
$name =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
$value =~ tr/+/ /;
$value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
$value =~ s/<!--(.|\n)*-->//g;
$HASH{$name} = $value;
}
}
Gunnar Hjalmarsson
> if (!HASH{search2}) {
-------^
> $search = "search1 only";
> }
> if (!HASH{search1} && !HASH{search2}){
-------^
Something is missing there...
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
Sherm Pendley
> I'll hack around this but curious why first use passes.
The first use passes because it doesn't have the same error.
> -----snip -----
>
> #!/usr/bin/perl
>
> use strict;
use warnings;
use CGI;
use CGI::Carp qw(fatalsToBrowser);
> my $search;
> my %HASH;
> my $name;
> my $value;
> my @pairs;
> my $buffer;
> my $pair;
>
> getweb();
Why are you reinventing that wheel? Have a look at the CGI module - it's
the standard for a reason. (If you're using a book that told you to do
that, take that book back for a refund, and buy one whose author actually
knows what he or she is talking about.)
Also, why are you using global variables for everything, and giving them
nonsensical names like %HASH? Those are bad habits in *any* language.
> if (!$HASH{search1}) {
> $search = "search2 only";
> }
>
> if (!HASH{search2}) {
^
$HASH
> $search = "search1 only";
> }
> if (!HASH{search1} && !HASH{search2}){
^ ^
$HASH $HASH
> $search = "no search";
> }
sherm--
--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net
gcr
Gunnar Hjalmarsson <nor...@gunnar.cc> wrote:
> gcr wrote:
> > if (!HASH{search2}) {
> -------^
>
> > $search = "search1 only";
> > }
> > if (!HASH{search1} && !HASH{search2}){
> -------^
>
> Something is missing there...
Ouch!! My bad - no sleep. Thanks and sorry for stupid question.
gcr
Sherm Pendley <spam...@dot-app.org> wrote:
Ouch! My Bad. Sorry, no sleep.
Side point - I've been burned a few times by cgi.pm so I gave up on it -
I didn't reinvent this wheel, though, I got it from someone and have
been using it for a while.
Sorry for the stupid question.
Sherm Pendley
> Side point - I've been burned a few times by cgi.pm so I gave up on it
If you get "burned" by something that literally *thousands* of other people
are using successfully, giving up and blaming the module is just silly.
> I didn't reinvent this wheel, though, I got it from someone and have
> been using it for a while.
So? It's still awful code, regardless of how long you've been using it. It
uses global variables, for pity's sake. You're claiming that the standard
module is somehow inferior, when the author of the code you're using now
doesn't even know how to return a value from a subroutine?
gcr
Sherm Pendley <spam...@dot-app.org> wrote:
> gcr <reviewy...@hotmail.com> writes:
>
> > Side point - I've been burned a few times by cgi.pm so I gave up on it
>
> If you get "burned" by something that literally *thousands* of other people
> are using successfully, giving up and blaming the module is just silly.
Line breaks - cgi.pm was inconsistent. This is a while back, may have
been fixed by now or maybe I didn't get it back then. There were also
big back and forths on the newsgroup by those more knowledgable than I
(that would be everyone) about the pluses and minuses of cgi.pm. I
haven't been burned *yet* by using the regexes and it's been in pretty
constant use for a while. I like to be able to control what is being
decoded for various reasons which I wasn't able to figure out in cgi.pm.
I've also fixed other peoples broken cgi's (again, linebreak issues) by
taking cgi.pm out and using regexes. YMMV.
> So? It's still awful code, regardless of how long you've been using it. It
> uses global variables, for pity's sake.
I added strict when posting to the NG and defined the variables on the
fly at the head for the example. The main HASH{} could be named WEB{} I
guess but I'm the only maintainer so it hasn't bothered me.
> You're claiming that the standard
> module is somehow inferior,
Not at all. *I* couldn't make it work, fault probably lies here. The
other code worked and hasn't broken yet. I moved on.
> when the author of the code you're using now
> doesn't even know how to return a value from a subroutine?
>
Unclear what you mean - again purely my ignorance. Like I said, this
code has run in various places for a while with no problems (besides
sheer idiocy like my parent posting which wasn't the code but PEBKAC)
Thanks for getting, anyways.
Tad McClellan
> In article <m21wnnm...@Sherm-Pendleys-Computer.local>,
> Sherm Pendley <spam...@dot-app.org> wrote:
>
>> gcr <reviewy...@hotmail.com> writes:
>>
>> > Side point - I've been burned a few times by cgi.pm so I gave up on it
>>
>> If you get "burned" by something that literally *thousands* of other people
>> are using successfully, giving up and blaming the module is just silly.
>
> Line breaks - cgi.pm was inconsistent.
Line breaks don't generally matter in the output of a CGI program (HTML).
--
Tad McClellan SGML consulting
ta...@augustmail.com Perl programming
Fort Worth, Texas
Gunnar Hjalmarsson
> gcr writes:
>>I didn't reinvent this wheel, though, I got it from someone and have
>>been using it for a while.
>
> So? It's still awful code, regardless of how long you've been using it. It
> uses global variables, for pity's sake. You're claiming that the standard
> module is somehow inferior,
As you well know, it _is_ inferior in one way: efficiency. Personally I
often use it because it's convenient, but in situations when efficiency
matters I don't. I have never understood why some regulars here get so
upset as soon as they see a piece of trivial CGI parsing code.
> when the author of the code you're using now
> doesn't even know how to return a value from a subroutine?
So, let's improve it a little:
my %HASH = getcgi();
sub getcgi {
my ($buffer, %params);
if ( $ENV{REQUEST_METHOD} eq 'POST' ) {
my $len = $ENV{CONTENT_LENGTH};
$len <= 131072 or die "Too much data submitted.\n";
binmode STDIN;
read( STDIN, $buffer, $len ) == $len
or die "Reading of posted data failed.\n";
} else {
$buffer = $ENV{QUERY_STRING};
}
$buffer =~ tr/+/ /;
for ( split /[&;]/, $buffer ) {
my ($name, $value) =
map { s/%(..)/chr(hex $1)/eg; $_ } split /=/, $_, 2;
$params{$name} = $value;
}
wantarray ? %params : \%params;
}
As regards the line
$value =~ s/<!--(.|\n)*-->//g;
in the OP's code, it's probably there to take care of <!--exec ... -->
constructs. Personally I always let user input pass this (or some
similar) function:
sub entify {
my $ref = defined wantarray ? [ @_ ] : \@_;
my %ent = ('&'=>'amp', '"'=>'quot', '<'=>'lt', '>'=>'gt');
s/([&"<>])/&$ent{$1};/g for grep defined, @$ref;
if ( defined wantarray ) {
@$ref > 1 ? @$ref : $$ref[0];
}
}
before it's presented in an HTML context. That takes care also of the
<!--exec ... --> issue.
Sherm Pendley
> Line breaks - cgi.pm was inconsistent. This is a while back, may have
> been fixed by now or maybe I didn't get it back then.
You didn't get it. There's nothing in the relevant standards the requires
line breaks to be consistent.
> There were also
> big back and forths on the newsgroup by those more knowledgable than I
> (that would be everyone) about the pluses and minuses of cgi.pm.
I highly doubt that. You're using homemade code instead of CGI.pm (spelling
matters) to parse input from a form. That particular use of CGI.pm hasn't
been the subject of any serious debate, at least among people who know what
they're talking about.
There *has* been some debate about the inclusion in CGI.pm of HTML-generating
functions. But those aren't what we're discussing here, and that train left
the station a long time ago anyway.
And, of course, there have been many discussions like this one, between
people who actually know what they're doing and others who seem to take
some kind of strange pride in writing bad code.
> I've also fixed other peoples broken cgi's (again, linebreak issues) by
> taking cgi.pm out and using regexes. YMMV.
Let me get this straight - you don't know what a global is, you don't know
what it means to return a value from a subroutine, and you *still* think
you're in a position to judge whether CGI.pm is worth using? You actually
believe you're qualified to not only call code that uses CGI.pm "broken",
but also that you're qualified to "fix" it????
Unbelieveable.
> Unclear what you mean - again purely my ignorance. Like I said, this
> code has run in various places for a while with no problems
You can repeat that as many times as you like - it won't change the fact
that rolling your own CGI parsing code is foolish, *especially* given the
low level of knowledge you've shown here concerning not only the CGI spec,
but programming in general.
Anyway, since you're apparently more interested in defending your ignorance
than curing it, I'm done with this.
Tad McClellan
> . I have never understood why some regulars here get so
> upset as soon as they see a piece of trivial CGI parsing code.
Then you probably were not here when 20% of all posts here got
it "trivially" wrong (mid '90's).
Since it is not in your experience, you will never understand,
so can you quit harping on it?
Gunnar Hjalmarsson
> Gunnar Hjalmarsson wrote:
>>. I have never understood why some regulars here get so
>>upset as soon as they see a piece of trivial CGI parsing code.
>
> Then you probably were not here when 20% of all posts here got
> it "trivially" wrong (mid '90's).
Right, I wasn't.
Mid 90's. Ten years. Maybe it's time to relax? :)
> Since it is not in your experience, you will never understand,
Probably not. Which is true also for other relative newcomers who are
picked on. While the tone occationally used, when commenting on this
matter here, serves no useful purpose, I'm convinced it unnecessarily
scares away a few.
> so can you quit harping on it?
I will, when the tone gets more sober.
But hey, things have improved. A couple of years ago, when someone
revealed that they were using their own code for parsing CGI, about 10
regulars told that person that s/he was stupid. Nowadays only one or two
regulars do the same thing. ;-)
Ben Morrow
Quoth Gunnar Hjalmarsson <nor...@gunnar.cc>:
> Sherm Pendley wrote:
> > gcr writes:
> >>I didn't reinvent this wheel, though, I got it from someone and have
> >>been using it for a while.
> >
> > So? It's still awful code, regardless of how long you've been using it. It
> > uses global variables, for pity's sake. You're claiming that the standard
> > module is somehow inferior,
>
> As you well know, it _is_ inferior in one way: efficiency. Personally I
> often use it because it's convenient, but in situations when efficiency
> matters I don't. I have never understood why some regulars here get so
> upset as soon as they see a piece of trivial CGI parsing code.
Because parsing CGI isn't as trivial as people think, and rewriting
rather than reusing even a fairly simple piece of code is a very bad
programming practice. If you can do it *correctly* more efficiently than
CGI.pm can, then by all means please release your code as
CGI::VeryEfficient or something, and then the rest of us can get the
benefit as well.
Personally, for the tiny amount of CGI stuff I've done I used CGI::Lite,
simply because the size of CGI.pm's perldoc daunted me somewhat; but
rewriting it for every CGI script is just daft.
Ben
--
Joy and Woe are woven fine,
A Clothing for the Soul divine William Blake
Under every grief and pine 'Auguries of Innocence'
Runs a joy with silken twine. benm...@tiscali.co.uk
Sherm Pendley
> As you well know, it _is_ inferior in one way: efficiency. Personally
> I often use it because it's convenient, but in situations when
> efficiency matters I don't.
In situations where efficiency matters, I'll take mod_perl any day. :-)
But seriously - the OP doesn't know what a global is. He doesn't know what
"return a value from a subroutine" means. Do you really think he profiled
his app and found CGI.pm to be a significant bottleneck?
I don't find it upsetting when a skilled developer has a good reason (such
as a profiler-verified bottleneck) for choosing not to use CGI.pm.
I find it quite upsetting when a newbie refuses to use it, and then argues
about it and invents specious excuses for what basically amounts to simple
contrariness.
Charlton Wilbur
>> There were also big back and forths on the newsgroup by those
>> more knowledgable than I (that would be everyone) about the
>> pluses and minuses of cgi.pm.
SP> I highly doubt that.
She whom I am not going to name - but she misspelled both Perl and
Girl in her nom de net - delivered frequent tirades about how useless
CGI.pm was. This might easily have been mistaken for a "big back and
forth" with significant support on both sides, especially as there
were more reasonable people who stepped forth with more nuanced
opinions about various parts of the CGI.pm module.
Charlton
--
Charlton Wilbur
cwi...@chromatico.net
Charlton Wilbur
GH> I have never understood why some regulars here get so upset as
GH> soon as they see a piece of trivial CGI parsing code.
Because CGI parsing is not trivial. It's the same reaction I have to
parsing HTML or XML with a complicated regular expression, or using
regular expressions for arithmetic: the fact that someone's trying it
seriously in the first place shows that they don't understand the
problem or the tool.
It's not a matter of being upset. It's a reaction to someone doing
something that is, in the vast majority of scenarios, somewhere
between misguided and idiotic; and in those scenarios where it isn't
counterproductive, there are other solutions with a much better return
on the investment of time.
Tad McClellan
> But hey, things have improved. A couple of years ago, when someone
> revealed that they were using their own code for parsing CGI, about 10
> regulars told that person that s/he was stupid. Nowadays only one or two
> regulars do the same thing. ;-)
Because there are now eight less regulars!
Charlton Wilbur
TMcC> Gunnar Hjalmarsson <nor...@gunnar.cc> wrote:
>> But hey, things have improved. A couple of years ago, when
>> someone revealed that they were using their own code for
>> parsing CGI, about 10 regulars told that person that s/he was
>> stupid. Nowadays only one or two regulars do the same
>> thing. ;-)
TMcC> Because there are now eight less regulars!
Eight fewer *knowledgeable* regulars, surely.
John W. Krahn
> Gunnar Hjalmarsson <nor...@gunnar.cc> wrote:
>
>>But hey, things have improved. A couple of years ago, when someone
>>revealed that they were using their own code for parsing CGI, about 10
>>regulars told that person that s/he was stupid. Nowadays only one or two
>>regulars do the same thing. ;-)
>
>
> Because there are now eight less regulars!
Probably up north helping Santa this time of the year. :-)
John
--
Perl isn't a toolbox, but a small machine shop where you can special-order
certain sorts of tools at low cost and in short order. -- Larry Wall
Tad McClellan
>>>>>> "TMcC" == Tad McClellan <ta...@augustmail.com> writes:
>
> TMcC> Gunnar Hjalmarsson <nor...@gunnar.cc> wrote:
>
> >> But hey, things have improved. A couple of years ago, when
> >> someone revealed that they were using their own code for
> >> parsing CGI, about 10 regulars told that person that s/he was
> >> stupid. Nowadays only one or two regulars do the same
> >> thing. ;-)
>
> TMcC> Because there are now eight less regulars!
>
> Eight fewer *knowledgeable* regulars, surely.
Or eight fewer *curmudgeonly* regulars, frankly.
Tad McClellan
> Tad McClellan wrote:
>> Gunnar Hjalmarsson <nor...@gunnar.cc> wrote:
>>
>>>But hey, things have improved. A couple of years ago, when someone
>>>revealed that they were using their own code for parsing CGI, about 10
>>>regulars told that person that s/he was stupid. Nowadays only one or two
>>>regulars do the same thing. ;-)
>>
>>
>> Because there are now eight less regulars!
>
> Probably up north helping Santa this time of the year. :-)
Well that's where the nice ones probably are.
The naughty ones are probably still here though...
Gunnar Hjalmarsson
> If you can do it *correctly* more efficiently than CGI.pm can,
Of course I can; just did.
http://groups.google.com/group/comp.lang.perl.misc/msg/827b6bb5568885f3
I.e. it does *correctly* what it's supposed to do. (It's not supposed to
handle e.g. multivalue fields or file uploads.)
> then by all means please release your code as CGI::VeryEfficient or
> something, and then the rest of us can get the benefit as well.
Since there already are alternative CGI parsing modules, there is no
need to release another one. If one of them was included in the standard
Perl distro, people might be more inclined to use it. I know I would.
Ben Morrow
Quoth Gunnar Hjalmarsson <nor...@gunnar.cc>:
> Ben Morrow wrote:
> > If you can do it *correctly* more efficiently than CGI.pm can,
>
> Of course I can; just did.
> http://groups.google.com/group/comp.lang.perl.misc/msg/827b6bb5568885f3
>
> I.e. it does *correctly* what it's supposed to do. (It's not supposed to
> handle e.g. multivalue fields or file uploads.)
I'm not really competent to judge whether it's correct, not having read
the CGI spec recently; as for 'more efficient', did you benchmark it?
Can we see the results?
> > then by all means please release your code as CGI::VeryEfficient or
> > something, and then the rest of us can get the benefit as well.
>
> Since there already are alternative CGI parsing modules, there is no
> need to release another one.
Then might I respectfully suggest that you point people at one of those,
instead of encouraging them to cargo-cult CGI-parsing code that a lot of
the time is either incorrect or not properly understood? It's hard
enough to get beginning programmers to understand the value of
modularity and code reuse as it is, without a whole lot of (almost
certainly spurious) argument about the efficiency or otherwise of
CGI.pm.
> If one of them was included in the standard Perl distro, people might
> be more inclined to use it. I know I would.
With pure-perl module such as we are talking it really doesn't matter if
it's in the perl core or not. It's trivial to install the module by hand
and point perl at it in even the most restricted of hosting
environments. XS modules are another matter, of course.
Ben
--
I must not fear. Fear is the mind-killer. I will face my fear and
I will let it pass through me. When the fear is gone there will be
nothing. Only I will remain.
benm...@tiscali.co.uk Frank Herbert, 'Dune'
Gunnar Hjalmarsson
> Quoth Gunnar Hjalmarsson:
>>Ben Morrow wrote:
>>>If you can do it *correctly* more efficiently than CGI.pm can,
>>
>>Of course I can; just did.
>>http://groups.google.com/group/comp.lang.perl.misc/msg/827b6bb5568885f3
>>
>>I.e. it does *correctly* what it's supposed to do. (It's not supposed to
>>handle e.g. multivalue fields or file uploads.)
>
> I'm not really competent to judge whether it's correct, not having read
> the CGI spec recently; as for 'more efficient', did you benchmark it?
Yes, several years ago.
> Can we see the results?
Sure.
http://groups.google.com/group/comp.lang.perl.misc/msg/d922a0fabe3ce436
>>Since there already are alternative CGI parsing modules, there is no
>>need to release another one.
>
> Then might I respectfully suggest that you point people at one of those,
> instead of encouraging them to cargo-cult CGI-parsing code that a lot of
> the time is either incorrect or not properly understood? It's hard
> enough to get beginning programmers to understand the value of
> modularity and code reuse as it is, without a whole lot of (almost
> certainly spurious) argument about the efficiency or otherwise of
> CGI.pm.
Spurious? BS! By making such a claim, without presenting any proofs,
your credibility is eroded.
If this _really_ was about the value of code reuse via modules, why does
nobody object to e.g. this message:
http://groups.google.com/group/comp.lang.perl.misc/msg/1b4d3a3b268bf35c
No, because people know and enjoy that TIMTOWTDI. But that philosophy
seems to not be applicable to the sacred cow CGI.pm. For some reason.
Understood only by those who were here 10 years ago.
kra...@visto.com
On Nov 28, 6:23 pm, gcr <reviewyourd...@hotmail.com> wrote:
> There were also
> big back and forths on the newsgroup by those more knowledgable than I
> (that would be everyone) about the pluses and minuses of cgi.pm. I
> haven't been burned *yet* by using the regexes and it's been in pretty
> constant use for a while. I like to be able to control what is being
> decoded for various reasons which I wasn't able to figure out in cgi.pm.
> I've also fixed other peoples broken cgi's (again, linebreak issues) by
> taking cgi.pm out and using regexes. YMMV.
What makes Perl so great is CPAN and all the available reliable
well-mantained quality modules.
Countless programmers have spent hours writing and mantaining module
code so we can have the capabilities to perform certain operations
trouble and stress free. This saves us from unneccessary development
time and headachs. You wouldn't spend hours and hours trying to
reinvent the wheel when the wheel is right infront of you ready to be
used.
What you have is a piece of code that dumps all parameters into Global
variables regardless of size. This will be stored in memory during the
duration of run time. Your sub form parsing technique is dated and
though may get the job done it also does ZERO error and safety handling
which makes it open to all sorts of future and present catastrophes.
You claim you want full control over how the form data is processed yet
you use it in the most generic way which makes your statement reflect
your inexperience even more so. If you have several CGIs and each use
the same copied sub-routine you are actually limiting functionality and
mantainability. Eventually you'd end up dumping the code in a module.
Then you will soon or later be forced into spending hours trying to
make your code more strict and bug free. Which would be reinventing the
wheel.
Modules are created for a reason. It's so programmers can use reliable
safe code instead of trying to reinvent the functionality of an
operation for every project. CGI.pm is the standard for parsing form
data if you choose not to use it you are only limiting yourself and
putting your web site, server and users at risk.
Gunnar Hjalmarsson
> ... it also does ZERO error and safety handling
<snip>
> CGI.pm is the standard for parsing form
> data if you choose not to use it you are only limiting yourself and
> putting your web site, server and users at risk.
Another one who naively believes that using CGI.pm for parsing the input
makes a significant difference as regards security.
It does not.
Sherm Pendley
> kra...@visto.com wrote:
>> ... it also does ZERO error and safety handling which makes it open
>> to all sorts of future and present catastrophes.
>
> <snip>
>
>> CGI.pm is the standard for parsing form data if you choose not to
>> use it you are only limiting yourself and putting your web site,
>> server and users at risk.
>
> Another one who naively believes that using CGI.pm for parsing the
> input makes a significant difference as regards security.
>
> It does not.
Gunnar, why do you persist with that straw-man argument? Pointing out the
fact that CGI.pm securely parses CGI arguments does not imply a claim that
doing so is all that's needed to securely write CGI applications.
This whole "skilled developers can improve upon CGI.pm, and shouldn't be
chastised for doing so" argument, while quite true, is irrelevant in this
case because is in fact *not* such a developer.
The OP frankly admitted to being incapable of even *using* CGI.pm correctly,
much less improving on it. He also admitted that he simply copy-and-pasted
the alternative code and doesn't understand how it works any more than he
does CGI.pm.
Such an individual is blindly trusting code he doesn't understand whether
he uses CGI.pm or not; the question is whether he should place such trust in
code that's been extensively community-reviewed, or in code he copied from
his neighbor's cousin's best friend's roommate.
Gunnar Hjalmarsson
> Gunnar Hjalmarsson writes:
>>kra...@visto.com wrote:
>>>... it also does ZERO error and safety handling which makes it open
>>>to all sorts of future and present catastrophes.
>>
>><snip>
>>
>>>CGI.pm is the standard for parsing form data if you choose not to
>>>use it you are only limiting yourself and putting your web site,
>>>server and users at risk.
>>
>>Another one who naively believes that using CGI.pm for parsing the
>>input makes a significant difference as regards security.
>>
>>It does not.
>
> Gunnar, why do you persist with that straw-man argument?
It's not straw-man, it's both true and significant.
> Pointing out the
> fact that CGI.pm securely parses CGI arguments does not imply a claim that
> doing so is all that's needed to securely write CGI applications.
1. He didn't just claim that CGI.pm makes a difference as regards
security, he talked about "putting your web site, server and users at
risk" if you choose to not use it.
2. My objection above does not include the message you indicate.
3. Still, my belief is that using such arguments for advocating the use
of CGI.pm _does_ give the incorrect impression that you write
significantly more secure CGI programs only by using it.
> This whole "skilled developers can improve upon CGI.pm, and shouldn't be
> chastised for doing so" argument, while quite true, is irrelevant in this
> case because is in fact *not* such a developer.
While I don't defend everything the OP in this thread said, neither do I
think that _anybody_ should be chastised for using a totally harmless
piece of code.
Point out the value of code reuse through modules, fine, that's good
advice. For god's sake, I'm also a module user (and author). I'm even
using CGI.pm from time to time. :)
But try to relax, and let it stay with that. Try to believe that the
readers of this group are grown-up people, who are capable of making
their own decisions on programming style.
kra...@visto.com
On Dec 3, 4:37 pm, Gunnar Hjalmarsson <nore...@gunnar.cc> wrote:
> 3. Still, my belief is that using such arguments for advocating the use
> of CGI.pm _does_ give the incorrect impression that you write
> significantly more secure CGI programs only by using it.
Gunnar, would you agree that if a programmer chooses to parse his/her
own form data the algorithm he/she uses must be thorough, complete and
well tested for reliability?
If so, would you advocate against using an identical sub-routine copied
through out 10 CGI scripts? Programming with practical and logical
sense you'd recommend the programmer to create a module with his/her
thorough reliable code, right?
If so (once again), why would you waste time rewriting an existing
module if it meets HTTP standards if you're only going to use it in the
most generic form?
Would you really tell someone who is inexperienced (or even
experienced) to go a head and waste their time and their employers buck
producing some over the night immature code? I wouldn't hire you.
Even you yourself use CGI.pm. In Contact::Form (the module you are the
author of) you have:
# create hash reference to the form data
my $in = new CGI->Vars;
Interesting.
Sherm Pendley
> While I don't defend everything the OP in this thread said, neither do
> I think that _anybody_ should be chastised for using a totally
> harmless piece of code.
My point isn't that the specific code used by the OP was harmful. It is that
the OP (by his own admission) lacks the experience to judge whether it is
harmful or not.
That being the case, the wisest course is to use the widely-known standard,
at least until one gains the experience to make an informed decision in the
matter for one's self. To do otherwise, to choose code of unknown provenance
that hasn't had the extensive amount of community review that CGI.pm has had,
is both risky and foolish.
I do agree with you to the extent that there are occasions where using CGI.pm
is not the best choice. Do you seriously believe that "I couldn't figure out
how to make it work" is such an occasion? Review the thread - that's exactly
the reason the OP gave for not using CGI.pm.
Gunnar Hjalmarsson
Ben Morrow
Quoth Gunnar Hjalmarsson <nor...@gunnar.cc>:
> Ben Morrow wrote:
> > Quoth Gunnar Hjalmarsson:
> >>Ben Morrow wrote:
> >>>If you can do it *correctly* more efficiently than CGI.pm can,
> >>
> >>Of course I can; just did.
> >>http://groups.google.com/group/comp.lang.perl.misc/msg/827b6bb5568885f3
> >>
> >>I.e. it does *correctly* what it's supposed to do. (It's not supposed to
> >>handle e.g. multivalue fields or file uploads.)
> >
> > I'm not really competent to judge whether it's correct, not having read
> > the CGI spec recently; as for 'more efficient', did you benchmark it?
>
> Yes, several years ago.
>
> > Can we see the results?
>
> Sure.
> http://groups.google.com/group/comp.lang.perl.misc/msg/d922a0fabe3ce436
OK, I can see there may be situations where that level of performance is
important. I still maintain it would be better practice to direct people
to a more efficient module if and when it becomes necessary, rather than
towards copy/pasting code.
> >>Since there already are alternative CGI parsing modules, there is no
> >>need to release another one.
> >
> > Then might I respectfully suggest that you point people at one of those,
> > instead of encouraging them to cargo-cult CGI-parsing code that a lot of
> > the time is either incorrect or not properly understood? It's hard
> > enough to get beginning programmers to understand the value of
> > modularity and code reuse as it is, without a whole lot of (almost
> > certainly spurious) argument about the efficiency or otherwise of
> > CGI.pm.
>
> Spurious? BS! By making such a claim, without presenting any proofs,
> your credibility is eroded.
Note the 'almost certainly' :). On the point of raw-speed-of-startup I
stand corrected. Whether this is the limiting factor in any one case
depends on what the CGI is doing, of course; I will believe you if you
say there are cases where it matters.
> If this _really_ was about the value of code reuse via modules, why does
> nobody object to e.g. this message:
> http://groups.google.com/group/comp.lang.perl.misc/msg/1b4d3a3b268bf35c
I would have, in principle. Those two programs are (IMHO) nasty, and are
wrong in several particulars. They should be replaced with LWP.
In practice, I don't correct every piece of bad code that passes through
my newsreader: I simply don't have the energy. You may have noticed that
I am rarely one of those who jumps on people who aren't using CGI.pm, I
am merely defending what I see as good practice on behalf of those who
do.
Ben
--
Musica Dei donum optimi, trahit homines, trahit deos. |
Musica truces mollit animos, tristesque mentes erigit.|benm...@tiscali.co.uk
Musica vel ipsas arbores et horridas movet feras. |
Gunnar Hjalmarsson
> Quoth Gunnar Hjalmarsson:
>>Ben Morrow wrote:
>>>as for 'more efficient', did you benchmark it?
>>
>>Yes, several years ago.
>>
>>>Can we see the results?
>>
>>Sure.
>>http://groups.google.com/group/comp.lang.perl.misc/msg/d922a0fabe3ce436
>
> OK, I can see there may be situations where that level of performance is
> important. I still maintain it would be better practice to direct people
> to a more efficient module if and when it becomes necessary, rather than
> towards copy/pasting code.
If somebody asks "how do I parse CGI data?" I don't give him/her any
code, but rather point at the applicable FAQ entry. This situation was
slightly different...
>>>It's hard
>>>enough to get beginning programmers to understand the value of
>>>modularity and code reuse as it is, without a whole lot of (almost
>>>certainly spurious) argument about the efficiency or otherwise of
>>>CGI.pm.
>>
>>Spurious? BS! By making such a claim, without presenting any proofs,
>>your credibility is eroded.
>
> Note the 'almost certainly' :).
Hmm... Okay.
> On the point of raw-speed-of-startup I
> stand corrected. Whether this is the limiting factor in any one case
> depends on what the CGI is doing, of course; I will believe you if you
> say there are cases where it matters.
That's all I say. There are also a lot of cases where it doesn't matter.
Ted Zlatanov
kra...@visto.com wrote:
>> ... it also does ZERO error and safety handling which makes it open
>> to all sorts of future and present catastrophes.
>
> <snip>
>
>> CGI.pm is the standard for parsing form data if you choose not to
>> use it you are only limiting yourself and putting your web site,
>> server and users at risk.
>
> Another one who naively believes that using CGI.pm for parsing the
> input makes a significant difference as regards security.
>
> It does not.
While your argument is interesting on its own, note that krakle didn't
specifically point to security, and the risk he mentions in your quote
is actually the risk of downtime and bugs. Security is not mentioned
in the article he posted. I checked carefully--at least that's how I
read it, and I think most would agree with my reading.
Ted
Gunnar Hjalmarsson
> On 3 Dec 2006, nor...@gunnar.cc wrote:
>> kra...@visto.com wrote:
>>>... it also does ZERO error and safety handling which makes it open
>>>to all sorts of future and present catastrophes.
>>
>><snip>
>>
>>>CGI.pm is the standard for parsing form data if you choose not to
>>>use it you are only limiting yourself and putting your web site,
>>>server and users at risk.
>>
>>Another one who naively believes that using CGI.pm for parsing the
>>input makes a significant difference as regards security.
>>
>>It does not.
>
> While your argument is interesting on its own, note that krakle didn't
> specifically point to security,
Note that not even krakle objected to my interpretation:
http://groups.google.com/group/comp.lang.perl.misc/msg/c09c0e267b8edf66
Anyway, as long as we are agreed that CGI.pm has little to do with
security, there is no point in speculating in what krakle actually meant.
kra...@visto.com
On Dec 4, 8:36 pm, Gunnar Hjalmarsson <nore...@gunnar.cc> wrote:
> Note that not evenkrakleobjected to my interpretation:http://groups.google.com/group/comp.lang.perl.misc/msg/c09c0e267b8edf66
>
> Anyway, as long as we are agreed that CGI.pm has little to do with
> security, there is no point in speculating in whatkrakleactually meant.
I didn't say anything about security. Since I referred ro CGI.pm's code
as "thorough, complete, and well tested for reliability" and the other
code as "limiting functionality and
mantainability" I didn't think I had to specify.
kra...@visto.com
On Dec 3, 5:35 pm, Gunnar Hjalmarsson <nore...@gunnar.cc> wrote:
>
> I see nothing about security in your comments above. Good.
>
Because I said nothing about security in my comments.
Martijn Lievaart
Just as an aside, security typically consists of CIA, Confidentially,
Integrity, Availability. Somehow, people often only look at the C when
thinking about security. Downtime is A and is important from a security
stance (and can have C and I impact as well). Bugs can lead to breaches of
any of the catagories so are a scurity hazard as well.
Security is the science of managing risks due to unforseen errors. It
should always be a analysis of risks versus the cost of avoiding them. But
making this analysis can be very hard in some situations. However, one can
avoid some of this analysis by laying a baseline of contra measures.
Secure coding should always be one of those baselines. If you google on it
there are some guidelines for that on the net.
(Do note that security guidelines are hard to find in general, because
many companies make their money that way and are not going to put there
guidelines up for the public).
M4
--
Redundancy is a great way to introduce more single points of failure.