[25092] in Perl-Users-Digest
Perl-Users Digest, Issue: 7342 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Oct 30 00:05:52 2004
Date: Fri, 29 Oct 2004 21:05:05 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Fri, 29 Oct 2004 Volume: 10 Number: 7342
Today's topics:
Re: Attempting to create a C .h file to an Assembly .in <dragontamer5788@yahoo.com>
compiler optimization <akopps+usenet@ocf.berkeley.edu.remuvthis.com>
Re: computing the checksum <usenet@morrow.me.uk>
Re: Convert String Containing Hex Values <jurgenex@hotmail.com>
Re: converting list to an array <see@sig.invalid>
Re: converting list to an array <nospam@nospam.com>
FAQ 8.38: How do I timeout a slow event? <comdog@panix.com>
Re: How to handle large variable <usenet@morrow.me.uk>
Re: modifying hash key (dispatch table) <usenet@morrow.me.uk>
Re: modifying hash key (dispatch table) <tadmc@augustmail.com>
Re: system return value makes for strange logic <jurgenex@hotmail.com>
web hoster won't secure CGI (wana)
Re: web hoster won't secure CGI <vilain@spamcop.net>
Re: web hoster won't secure CGI <1usa@llenroc.ude.invalid>
Re: web hoster won't secure CGI <emschwar@pobox.com>
Re: web hoster won't secure CGI <matthew.garrish@sympatico.ca>
Re: web hoster won't secure CGI <comdog@panix.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 29 Oct 2004 22:47:39 -0400
From: Percival <dragontamer5788@yahoo.com>
Subject: Re: Attempting to create a C .h file to an Assembly .inc file
Message-Id: <2ugdkfF2afffeU1@uni-berlin.de>
Tassilo v. Parseval wrote:
> h2xs, the utility that creates a Perl module skeleton from a C-header,
> is capable of parsing enums. The parsing looks like this:
>
> no warnings 'uninitialized';
>
> # Remove C and C++ comments
> $src =~ s#/\*[^*]*\*+([^/*][^*]*\*+)*/|("(\\.|[^"\\])*"|'(\\.|[^'\\])*'|.[^/"'\\]*)#$2#gs;
>
> # The while loop iterates over one complete enum-block:
> while ($src =~ /(\benum\s*([\w_]*)\s*\{\s([\s\w=,]+)\})/gsc) {
> my ($enum_name, $enum_body) =
> $1 =~ /enum\s*([\w_]*)\s*\{\s([\s\w=,]+)\}/gs;
> my $val = 0;
> for my $item (split /,/, $enum_body) {
> my ($key, $declared_val) = $item =~ /(\w*)\s*=\s*(.*)/;
> $val = length($declared_val) ? $declared_val : 1 + $val;
> # $key is now the constant name, $val its value
> }
> }
>
> For that to work, it's necessary to slurp the whole header into $src. It
> doesn't work if you try to process the file linewise. Also, C comments
> (that may show up in enums, too) have to be stripped.
>
> Having a closer look at the above, I think it doesn't catch all cases.
> Most notably, it should fail on:
>
> enum id { CONSTANT };
>
> That is: It should fail when only one key is in the enumeration.
>
> Tassilo
Thank you very much, I'll find a way to deal with that failure case.
Thanks for the program, it looks like it does what i need! Just want to
give one last question... doesn't \w include _? So [\w_] is a waste,
just stick with \w . But you are the expert, not me :)
Percival
------------------------------
Date: Sat, 30 Oct 2004 02:41:57 +0000 (UTC)
From: Akop Pogosian <akopps+usenet@ocf.berkeley.edu.remuvthis.com>
Subject: compiler optimization
Message-Id: <cluv1l$fmr$1@agate.berkeley.edu>
What's a reasonable optimization level to use when compiling
perl 5.8.5 with gcc 3.4 on Solaris 8?
-akop
------------------------------
Date: Fri, 29 Oct 2004 20:09:24 +0100
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: computing the checksum
Message-Id: <44ha52-mc6.ln1@osiris.mauzo.dyndns.org>
Quoth Spin <cNaOlSePbA@MvPeLtEsAtSaEr.com>:
> I need to compute the checksum on a hex message sent to a lab machine
> via Device::SerialPort.
>
> This is the C code snippet and instructions in their manual:
> Assume the message is held in buf. "buf" is an array of unsigned char.
>
> unsigned char *buf
> short int message_size;
> unsigned char trailer[2];
> trailer[0] = 0;
> for (int i = 0; i < message_size; i++)
> trailer[0] += buf[i];
> trailer[0] |= 0x80; // Turning on high bite ensures this cannot be an
> ETX byte
> trailer[1] = 0x03; // End of message ETX
>
> Here's what I have in my perl script (note I'm just printing to screen
> at this point, not to the device):
> #!/usr/bin/perl -w
> use strict;
> use Term::ANSIColor;
> my $status = chr(02); # Start of message (STX)
> $status .= chr(hex(30));
> $status .= chr(hex(33));
> $status .= chr(hex(80));
> $status .= chr(hex(86));
> $status .= chr(hex(53));
> $status .= chr(hex(50));
> $status .= chr(hex(20));
> $status .= chr(hex(20));
> $status .= chr(hex(20));
> $status .= chr(hex(73));
This could be better written
my $status = "\x02\x30\x33\x80\x86\x53\x50\x20\x20\x20\x73";
> my $check_sum = 0;
> my @reroute = unpack("H2"x length($status),$status);
> for my $i (0 .. 10) {
> $check_sum += hex($reroute[$i]);
Why are you doing this? Better would be
for (split //, $status) {
$check_sum += ord;
}
However, the C program seems to be relying on the fact that + for a char
will wrap around, so you want
$check_sum %= 256;
as well.
> print $reroute[$i];
> $i++;
> }
> $check_sum |= hex(0x80);
$check_sum |= 0x80;
> $status .= hex($check_sum);
$status .= chr($check_sum) . chr(03);
> $status .= chr(03);
> print color("red"), $check_sum, color("reset");
> print unpack("H*",$status),"\n";
>
> I know from their example that the checksum byte should be:
> $status .= chr(hex(89));
print "Corrext cksum" if $check_sum == 0x89;
What is your problem?
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. ben@morrow.me.uk
------------------------------
Date: Sat, 30 Oct 2004 01:35:01 GMT
From: "Jürgen Exner" <jurgenex@hotmail.com>
Subject: Re: Convert String Containing Hex Values
Message-Id: <9dCgd.82$vB.73@trnddc03>
cp wrote:
> If I have a string that looks like this:
>
> Job_x0020_Number
>
> How do I turn that into:
>
> Job Number
What about
s/_.*_/ /;
jue
------------------------------
Date: Fri, 29 Oct 2004 19:09:08 -0400
From: Bob Walton <see@sig.invalid>
Subject: Re: converting list to an array
Message-Id: <4182cb65_3@127.0.0.1>
daniel kaplan wrote:
> "A. Sinan Unur" <usa1@llenroc.ude.invalid> wrote in message
> news:Xns9591A56198348asu1cornelledu@132.236.56.8...
>
>
>>Then you should check if $pop->ping($user); actually succeeded. If it did
>>not succeed, then you should investiage why not.
>
>
> ding ding ding, a cupie doll for you! am so UNUSED to open
> source, I didn't think that I could debug INTO the Net::Pop3
-----------------------------------------------------------^^
Do you perhaps mean Net::POP3 ?? Case matters.
> code. Which on your recommendation I did, and I do
> believe that it is returning me a NULL! Now am still new enough that
------------------------------------^^^^
Probably actually an empty list since you're calling it in a list
context. There isn't anything designated as a NULL in Perl. There is
undef, the empty string, zero, the zero string, an empty list, maybe
even an empty hash, but no NULL. Picky point, perhaps, but accurate
communication requires the proper use of terminology. No one will be
sure just what you're trying to say if you say NULL.
> I have enough headaches debugging my own code much less someone
> else's. and mind you not saying there is a bug there, but according to
> the Net::Pop3 docs I should be getting back a list of two elements when
> there are items in my mailbox (which there are).
Actually, from the Net::POP3 docs:
"Unless otherwise stated all methods return either a true or false
value, with true meaning that the operation was a success. When a method
states that it returns a value, failure will be returned as undef or an
empty list."
Thus, if the method failed, you would get an empty list. Which you
apparently are. Conclusion: Your call to ->ping() failed for some
reason. You should test for that, and aim your debugging efforts at why
the call might fail.
...
--
Bob Walton
Email: http://bwalton.com/cgi-bin/emailbob.pl
------------------------------
Date: Fri, 29 Oct 2004 19:16:38 -0400
From: "daniel kaplan" <nospam@nospam.com>
Subject: Re: converting list to an array
Message-Id: <1099092025.754937@nntp.acecape.com>
"Bob Walton" <see@sig.invalid> wrote in message news:4182cb65_3@127.0.0.1...
> Do you perhaps mean Net::POP3 ?? Case matters.
yes you are correct, apologies
>There isn't anything designated as a NULL in Perl. There is
> undef, the empty string, zero, the zero string, an empty list, maybe
> even an empty hash, but no NULL.
yeah, NULL is another hardwired into my brain
> Thus, if the method failed, you would get an empty list. Which you
> apparently are. Conclusion: Your call to ->ping() failed for some
> reason. You should test for that, and aim your debugging efforts at why
> the call might fail.
i tend to agree and will ahev to spend more time without, every other call
to the
Net::POP3 object succeds...will look further into it
thanks for your points
------------------------------
Date: Sat, 30 Oct 2004 04:03:03 +0000 (UTC)
From: PerlFAQ Server <comdog@panix.com>
Subject: FAQ 8.38: How do I timeout a slow event?
Message-Id: <clv3pn$p7o$1@reader1.panix.com>
This message is one of several periodic postings to comp.lang.perl.misc
intended to make it easier for perl programmers to find answers to
common questions. The core of this message represents an excerpt
from the documentation provided with Perl.
--------------------------------------------------------------------
8.38: How do I timeout a slow event?
Use the alarm() function, probably in conjunction with a signal handler,
as documented in "Signals" in perlipc and the section on ``Signals'' in
the Camel. You may instead use the more flexible Sys::AlarmCall module
available from CPAN.
The alarm() function is not implemented on all versions of Windows.
Check the documentation for your specific version of Perl.
--------------------------------------------------------------------
Documents such as this have been called "Answers to Frequently
Asked Questions" or FAQ for short. They represent an important
part of the Usenet tradition. They serve to reduce the volume of
redundant traffic on a news group by providing quality answers to
questions that keep coming up.
If you are some how irritated by seeing these postings you are free
to ignore them or add the sender to your killfile. If you find
errors or other problems with these postings please send corrections
or comments to the posting email address or to the maintainers as
directed in the perlfaq manual page.
Note that the FAQ text posted by this server may have been modified
from that distributed in the stable Perl release. It may have been
edited to reflect the additions, changes and corrections provided
by respondents, reviewers, and critics to previous postings of
these FAQ. Complete text of these FAQ are available on request.
The perlfaq manual page contains the following copyright notice.
AUTHOR AND COPYRIGHT
Copyright (c) 1997-2002 Tom Christiansen and Nathan
Torkington, and other contributors as noted. All rights
reserved.
This posting is provided in the hope that it will be useful but
does not represent a commitment or contract of any kind on the part
of the contributers, authors or their agents.
------------------------------
Date: Fri, 29 Oct 2004 19:52:17 +0100
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: How to handle large variable
Message-Id: <14ga52-mc6.ln1@osiris.mauzo.dyndns.org>
Quoth Arndt Jonasson <do-not-use@invalid.net>:
>
> Exactly how vague is one allowed to be without misleading, when saying
> things about 'undef', I wonder. "$x has no value", "$x is undefined",
> "$x has the value 'undef'", "$x has the undefined value", "$x is set
> to nothing". Which of these are OK? I haven't picked up the common
> Perl speech patterns yet.
I would say (though I'm no authority) that '$x is undefined', '$x is
undef' or '$x has the undefined value' are all unambiguous, with the
seconed being preferred for brevity. '$x has no value' may be OK in some
contexts, but (e.g.) in the context of hash members it would be unclear
whether you mean
exists($x) and !defined($x)
or
!exists($x)
'$x is undefined' can be confusing also: for instance (to take an
example from another thread) I would be tempted to say that in
my $x if $y;
'$x is undefined' if $y is false; here I would *NOT* mean '$x = undef'
but rather that $x might be *anything*, undef or otherwise... so
probably best avoid that one, too.
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.
ben@morrow.me.uk Frank Herbert, 'Dune'
------------------------------
Date: Fri, 29 Oct 2004 19:44:34 +0100
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: modifying hash key (dispatch table)
Message-Id: <ilfa52-mc6.ln1@osiris.mauzo.dyndns.org>
Quoth Arndt Jonasson <do-not-use@invalid.net>:
>
> Tad McClellan <tadmc@augustmail.com> writes:
> > My personal style is to never use ampersands on sub calls, whether
> > called direct or via a coderef, I always use parens on sub calls
> > instead (even when they take no args).
>
> I was going to ask whether that was true even for 'eof', since the
> calls "eof" and "eof()" behave differently, but I suppose 'eof' is not
> a subroutine, but a built-in function.
Can you give an example of that?
Builtins behave exactly as though they were user-defined functions.
Ben
--
If I were a butterfly I'd live for a day, / I would be free, just blowing away.
This cruel country has driven me down / Teased me and lied, teased me and lied.
I've only sad stories to tell to this town: / My dreams have withered and died.
ben@morrow.me.uk (Kate Rusby)
------------------------------
Date: Fri, 29 Oct 2004 20:48:37 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: modifying hash key (dispatch table)
Message-Id: <slrnco5snl.23d.tadmc@magna.augustmail.com>
Ben Morrow <usenet@morrow.me.uk> wrote:
>
> Quoth Arndt Jonasson <do-not-use@invalid.net>:
>>
>> Tad McClellan <tadmc@augustmail.com> writes:
>> > My personal style is to never use ampersands on sub calls, whether
>> > called direct or via a coderef, I always use parens on sub calls
>> > instead (even when they take no args).
>>
>> I was going to ask whether that was true even for 'eof', since the
>> calls "eof" and "eof()" behave differently, but I suppose 'eof' is not
>> a subroutine, but a built-in function.
>
> Can you give an example of that?
The 2nd paragraph in
perldoc -f eof
does that.
> Builtins behave exactly as though they were user-defined functions.
Except for this function.
(not really, there are others too, but it sounds more dramatic that way :-)
It wouldn't be Perl if it didn't have Special Cases. <smiley or frowny?>
chomp() _must_ use parenthesis for some cases, where no-parens
on user subs will work fine for the same cases:
------------------------
#!/usr/bin/perl
use warnings;
use strict;
sub mychomp { s#$/$## for @_ }
my $s1 = "just another\n";
my $s2 = "Perl hacker\n";
chomp $s1, $s2; # warning Will Robinson
print "s1 '$s1'\n";
print "s2 '$s2'\n"; # Oops!
$s1 = "just another\n"; # all of the following work fine though
$s2 = "Perl hacker\n";
chomp($s1, $s2);
print "s1 '$s1'\n";
print "s2 '$s2'\n";
$s1 = "just another\n";
$s2 = "Perl hacker\n";
mychomp $s1, $s2;
print "s1 '$s1'\n";
print "s2 '$s2'\n";
$s1 = "just another\n";
$s2 = "Perl hacker\n";
mychomp($s1, $s2);
print "s1 '$s1'\n";
print "s2 '$s2'\n";
------------------------
What *I* don't understand though is why
perl -ne 'print if /^=item.*\(/' `perldoc -l perlfunc`
finds
=item chop( LIST )
instead of
=item chop LIST
<time passes while I try chop()s in the above program...>
Oh.
_Now_ I don't understand why the doc's for chop() don't say anything
about parens like chomp()'s docs do.
"See also chomp" would still leave me wondering if the parens
where a chomp-only thing or not...
Does that sound like a docs bug to anybody else?
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Sat, 30 Oct 2004 01:48:13 GMT
From: "Jürgen Exner" <jurgenex@hotmail.com>
Subject: Re: system return value makes for strange logic
Message-Id: <xpCgd.86$vB.67@trnddc03>
wana wrote:
> system("mysqladmin --user='$user' --password='$pass' create $db")
> or die "$db not created due to error\n";
>
> The function lead to die being called and printing the error message
> but the database was being created successfully. I changed it to:
>
> system("mysqladmin --user='$user' --password='$pass' create $db")
> and die "$db not created due to error\n";
>
> and even though it doesn't look right at first glance, it makes sense
> because system apparently returns 0 with success and numbers > 0 for
> failure.
Why don't you just check the documentation for the functions you are using?
It's explained right there in the third paragraph of "perldoc -f system".
jue
------------------------------
Date: 29 Oct 2004 17:02:00 -0700
From: ioneabu@yahoo.com (wana)
Subject: web hoster won't secure CGI
Message-Id: <bf0b47ca.0410291602.771b40e5@posting.google.com>
According to Lincoln Stein's book on CGI.pm, to make CGI safe, you
have to make configuration changes at the beginning of the CGI.pm
file. I asked my web hosting company if they had made these changes
to protect me from multi-megabyte uploads or large entries in
textfields and they told me that they make no changes to Perl modules
and I have no access to it myself.
Is there another way to provide this protection?
Thanks,
wana
------------------------------
Date: Fri, 29 Oct 2004 17:41:23 -0700
From: "Michael Vilain <vilain@spamcop.net>"
Subject: Re: web hoster won't secure CGI
Message-Id: <vilain-577341.17412329102004@news.giganews.com>
In article <bf0b47ca.0410291602.771b40e5@posting.google.com>,
ioneabu@yahoo.com (wana) wrote:
> According to Lincoln Stein's book on CGI.pm, to make CGI safe, you
> have to make configuration changes at the beginning of the CGI.pm
> file. I asked my web hosting company if they had made these changes
> to protect me from multi-megabyte uploads or large entries in
> textfields and they told me that they make no changes to Perl modules
> and I have no access to it myself.
>
> Is there another way to provide this protection?
>
> Thanks,
>
> wana
Don't use CGI.pm. Pick up a copy of CGI Programming on the World Wide
Web (1996, the 1st edition--NOT the 2nd), from O'Reilly, if you can find
it. It describes the process of CGI without using the CGI.pm module.
There's a routine you can use instead of the CGI::params routine. You
can tweak it to your hearts content to make it as bullet proof as you
want. Or could just dump the web hosting company you have for someone
who's more customer service oriented.
Here's the code from that book:
In the main script, call the function:
&parse_form_data(*FORM);
which will put your variables into the %FORM hash.
and here's the routine:
sub parse_form_data
{
local (*FORM_DATA) = @_;
local ( $request_method, $query_string, @key_value_pairs,
$key_value, $key, $value, $arg_value, $arg_index );
$request_method = $ENV{'REQUEST_METHOD'};
if ( $request_method eq "" && $ENV{'SHELL'} ne "" ) {
$request_method = "SHELL";
}
if ($request_method eq "GET") {
$query_string = $ENV{'QUERY_STRING'};
} elsif ($request_method eq "POST") {
read (STDIN, $query_string, $ENV{'CONTENT_LENGTH'});
} elsif ($request_method eq "SHELL") {
#
# for the shell, build a string of arguments so it can be
# parsed later on
#
$arg_index = 1;
foreach $arg_value (@ARGV) {
$arg_value =~ s/=/%3D/g;
$value = sprintf ("ARG%d=%s",$arg_index,$arg_value);
if ($arg_index == 1) {
$query_string = $value;
} else {
$query_string = join ("&", $query_string, $value);
}
$arg_index++;
}
} else {
&return_error (500, "Server Error",
"Server uses unsupported method");
}
@key_value_pairs = split (/&/, $query_string);
foreach $key_value (@key_value_pairs) {
($key, $value) = split (/=/, $key_value);
$value =~ tr/+/ /;
$value =~ s/%([\dA-Fa-f][\dA-Fa-f])/pack ("C", hex ($1))/eg;
$value =~ s/[;><&\*`\|\!]//g; # prevent sub-shell nasties
if (defined($FORM_DATA{$key})) {
$FORM_DATA{$key} = join ("\0", $FORM_DATA{$key}, $value);
} else {
$FORM_DATA{$key} = $value;
}
}
}
I stopped using this when CGI.pm came out and haven't looked back since.
--
DeeDee, don't press that button! DeeDee! NO! Dee...
------------------------------
Date: 30 Oct 2004 01:02:40 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: web hoster won't secure CGI
Message-Id: <Xns9591D6144D66Aasu1cornelledu@132.236.56.8>
"Michael Vilain <vilain@spamcop.net>" wrote in news:vilain-
577341.17412329102004@news.giganews.com:
> In article <bf0b47ca.0410291602.771b40e5@posting.google.com>,
> ioneabu@yahoo.com (wana) wrote:
>
>> According to Lincoln Stein's book on CGI.pm, to make CGI safe, you
>> have to make configuration changes at the beginning of the CGI.pm
>> file. I asked my web hosting company if they had made these changes
>> to protect me from multi-megabyte uploads or large entries in
>> textfields and they told me that they make no changes to Perl modules
>> and I have no access to it myself.
Read the CGI.pm documentation:
http://search.cpan.org/~lds/CGI.pm-
3.05/CGI.pm#Avoiding_Denial_of_Service_Attacks
...
> Don't use CGI.pm. Pick up a copy of CGI Programming on the World Wide
> Web (1996, the 1st edition--NOT the 2nd), from O'Reilly, if you can
> find it.
OK ... The blind leading the deaf or whatever the phrase is comes to
mind. Now, Gunnar, before you interject and say "it is OK not to use CGI
for such and such reasons", let me point out that it is not OK for this
particular poster to do that before actually learning Perl.
> Here's the code from that book:
>
> In the main script, call the function:
>
> &parse_form_data(*FORM);
Do you know what the & does? What's up with the typeglob?
> which will put your variables into the %FORM hash.
>
> and here's the routine:
>
> sub parse_form_data
> {
> local (*FORM_DATA) = @_;
>
> local ( $request_method, $query_string, @key_value_pairs,
> $key_value, $key, $value, $arg_value, $arg_index );
Oh, beautiful!
> @key_value_pairs = split (/&/, $query_string);
Ta - da!
> I stopped using this when CGI.pm came out and haven't looked
> back since.
Your advice above and this statement contradict each other. I think you
should follow the latter.
Sinan.
--
A. Sinan Unur
1usa@llenroc.ude.invalid
(remove '.invalid' and reverse each component for email address)
------------------------------
Date: Fri, 29 Oct 2004 19:07:24 -0600
From: Eric Schwartz <emschwar@pobox.com>
Subject: Re: web hoster won't secure CGI
Message-Id: <etosm7xc8tv.fsf@wilson.emschwar>
"Michael Vilain <vilain@spamcop.net>" writes:
> Don't use CGI.pm.
Wow, what a bad idea, in 90% of cases, including yours.
> Here's the code from that book:
>
> In the main script, call the function:
>
> &parse_form_data(*FORM);
Wow, I can think of at least three things wrong with that function
call already-- can you?
> which will put your variables into the %FORM hash.
>
> and here's the routine:
>
> sub parse_form_data
> {
> local (*FORM_DATA) = @_;
Why would you do this? eeeevil. If you must do such a thing, declare
the hash %FORM_DATA with 'my', and return it at the end of this
function. Better yet, don't, and use CGI.pm.
> local ( $request_method, $query_string, @key_value_pairs,
> $key_value, $key, $value, $arg_value, $arg_index );
All bad! Use lexical variables here instead. It's easy enough to
do-- swap 'my' for 'local' there. You haven't had to use 'local' for
private variables since perl 5 came out ages and ages ago. It's also
bad style in general to use package variables when they aren't needed.
> $request_method = $ENV{'REQUEST_METHOD'};
> if ( $request_method eq "" && $ENV{'SHELL'} ne "" ) {
> $request_method = "SHELL";
> }
Note: CGI.pm handles all this for you. And better than this code
does.
> if ($request_method eq "GET") {
> $query_string = $ENV{'QUERY_STRING'};
> } elsif ($request_method eq "POST") {
> read (STDIN, $query_string, $ENV{'CONTENT_LENGTH'});
You don't check that you read $ENV{CONTENT_LENGTH} (no quotes needed
there, or anywhere you have used a hash here. That could be bad, but
you'll never know!
> } elsif ($request_method eq "SHELL") {
> #
> # for the shell, build a string of arguments so it can be
> # parsed later on
> #
> $arg_index = 1;
> foreach $arg_value (@ARGV) {
> $arg_value =~ s/=/%3D/g;
> $value = sprintf ("ARG%d=%s",$arg_index,$arg_value);
> if ($arg_index == 1) {
> $query_string = $value;
> } else {
> $query_string = join ("&", $query_string, $value);
> }
> $arg_index++;
> }
You don't do proper URL escaping on your keys or values there. CGI.pm
handles this properly.
> } else {
> &return_error (500, "Server Error",
> "Server uses unsupported method");
Why are you calling functions with &? That hasn't been necessary for
years now.
> }
>
> @key_value_pairs = split (/&/, $query_string);
What if your user agent submits parameters separated by ';' instead of
'&'? This is perfectly legal to do, and you don't handle it at all.
> foreach $key_value (@key_value_pairs) {
> ($key, $value) = split (/=/, $key_value);
> $value =~ tr/+/ /;
> $value =~ s/%([\dA-Fa-f][\dA-Fa-f])/pack ("C", hex ($1))/eg;
I haven't checked, but I would bet this isn't a complete URL-decoding
algorithm.
> $value =~ s/[;><&\*`\|\!]//g; # prevent sub-shell nasties
What sub shell? I see no sub shell here....
> if (defined($FORM_DATA{$key})) {
> $FORM_DATA{$key} = join ("\0", $FORM_DATA{$key}, $value);
Ick. How annoying; it makes you manually detect multiple values
yourself and parse them out again manually. CGI.pm will happily hand
you an list if you get multiple values for one named parameter.
> } else {
> $FORM_DATA{$key} = $value;
> }
> }
> }
>
>
> I stopped using this when CGI.pm came out and haven't looked back since.
Good advice! I was afraid you were still using this rather buggy
code. I would advise anyone else still using this code to stop using
it as well, and use CGI.pm.
And to forestall Gunnar, yes, it is possible to write your own correct
URL-parsing code, if you know what you're doing. This isn't it.
That's why, unless you have a good reason not to, you should use
CGI.pm.
-=Eric
--
Come to think of it, there are already a million monkeys on a million
typewriters, and Usenet is NOTHING like Shakespeare.
-- Blair Houghton.
------------------------------
Date: Fri, 29 Oct 2004 20:54:47 -0400
From: "Matt Garrish" <matthew.garrish@sympatico.ca>
Subject: Re: web hoster won't secure CGI
Message-Id: <nDBgd.25720$Qs6.1912000@news20.bellglobal.com>
"wana" <ioneabu@yahoo.com> wrote in message
news:bf0b47ca.0410291602.771b40e5@posting.google.com...
> According to Lincoln Stein's book on CGI.pm, to make CGI safe, you
> have to make configuration changes at the beginning of the CGI.pm
> file. I asked my web hosting company if they had made these changes
> to protect me from multi-megabyte uploads or large entries in
> textfields and they told me that they make no changes to Perl modules
> and I have no access to it myself.
>
You should be more specific, because most people will probably not have read
the book. With respect to the example you cite, there's no reason why you
would need to change anything in the source. If you read the documentation
for the module you will quickly discover how to accomplish what you're after
(see in particular the section "Avoiding Denial of Service Attacks"). I do
find it a bit hard to believe that he would have only mentioned the source
code method in his book, though.
Matt
------------------------------
Date: Fri, 29 Oct 2004 20:50:32 -0500
From: brian d foy <comdog@panix.com>
To: ioneabu@yahoo.com (wana)
Subject: Re: web hoster won't secure CGI
Message-Id: <291020042050326622%comdog@panix.com>
[[ This message was both posted and mailed: see
the "To," "Cc," and "Newsgroups" headers for details. ]]
In article <bf0b47ca.0410291602.771b40e5@posting.google.com>, wana
<ioneabu@yahoo.com> wrote:
> According to Lincoln Stein's book on CGI.pm, to make CGI safe, you
> have to make configuration changes at the beginning of the CGI.pm
> file. I asked my web hosting company if they had made these changes
> to protect me from multi-megabyte uploads or large entries in
> textfields and they told me that they make no changes to Perl modules
> and I have no access to it myself.
> Is there another way to provide this protection?
You don't need to change the module itself because you can set the
variable values yourself. Load CGI.pm, then change the values.
use CGI;
$CGI::PRIVATE_TEMPFILES = 1;
my $query = CGI->new();
You can install your own version of CGI.pm and change it how you
like. Just tell your script how to where to find it.
Maybe the world needs an interface to all of these variables, so
you could just use something like:
CGI->enable_private_tempfiles;
CGI->set_post_max( 1024 );
--
brian d foy, comdog@panix.com
Subscribe to The Perl Review: http://www.theperlreview.com
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 7342
***************************************
