PERL Skipping a Call to a Sub.

Greetings,

I am coding up an online order entry application and its been going
fairly well but I have run into a roadblock on something I know is
going to be a head slapper. It seems unlikely but it almost appears as
if the call to LogAttack is being skipped over. Can you spot anything
wrong?

I have the following code snippet:
================
my $TextFieldValue = $SubFields->param($FieldName);
my $SubmittingIP = $SubFields->param('ip');
if(CSSAttack($TextFieldValue)) {
print LOGFILE "about to log attack.\n";
LogAttack($SubmittingIP, $AttackLogFile, "CSS Attack",
$FieldName, $TextFieldValue);
print LOGFILE "Past LogAttack.\n";
}
================

Both the pre & post call log entries show up in my general log, but I
see no indication PERL actually falls down into the LogAttack code.

Now, I have various print statements to create entries in my general
log but none of them show up, not even the first one. Nor does the
application crash as the form returns to the browser in roughly the
state I expect it.


Below is the code for LogAttack
============================
sub LogAttack() {
#Subroutine to log suspected attacks.
#Take in the cgi object, the path & attack log file, field name, &
value
#Format a log entry with time, date, IP of attack, type of attack,
field name, & value and write to the Attack Log
print LOGFILE "in LogAttack\n";
my $AttackingIP = $_[0];
my $AttackLogFile = $_[1];
my $AttackType = $_[2];
my $SuspectField = $_[3];
my $BadValue = $_[4];

my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) =
localtime(time);
$year += 1900;
my $Month = $mon + 1;

my $DateString = sprintf("%04d-%02d-%0sd %02d:%02d:%02d",$year,
$Month, $mday, $hour, $min, $sec);

#Obtain attacker's IP address
my $AttackMessage = sprintf("Attack type %s coming from IP
%s. Field: %s. Value: %s.", $AttackType, $AttackingIP, $SuspectField,
$BadValue);

my $LogEntry = sprintf("%s > %s\n", $DateString,
$AttackMessage);
my $AttackLogPathName = sprintf(">>%s", $AttackLogFile);
open(ATTACKLOGFILE, $AttackLogPathName) or die "\n Can not open
$AttackLogPathName\n";
print LOGFILE $AttackLogPathName;
print LOGFILE $LogEntry;
print ATTACKLOGFILE $LogEntry;
close ATTACKLOGFILE;
}
============================

Thanks for any & all help.
Mark

Re: PERL Skipping a Call to a Sub.

framness writes:

> Greetings,
>
> I am coding up an online order entry application and its been going
> fairly well but I have run into a roadblock on something I know is
> going to be a head slapper. It seems unlikely but it almost appears as
> if the call to LogAttack is being skipped over. Can you spot anything
> wrong?

[...]

> Below is the code for LogAttack
> ============================
> sub LogAttack() {
^^

Try dropping the parens.

--
Joe Schaefer

Re: PERL Skipping a Call to a Sub.

framness wrote in comp.lang.perl.misc:
> Greetings,
>
> I am coding up an online order entry application and its been going
> fairly well but I have run into a roadblock on something I know is
> going to be a head slapper. It seems unlikely but it almost appears as
> if the call to LogAttack is being skipped over. Can you spot anything
> wrong?
>
> I have the following code snippet:
> ================
> my $TextFieldValue = $SubFields->param($FieldName);
> my $SubmittingIP = $SubFields->param('ip');
> if(CSSAttack($TextFieldValue)) {
> print LOGFILE "about to log attack.\n";
> LogAttack($SubmittingIP, $AttackLogFile, "CSS Attack",
> $FieldName, $TextFieldValue);
> print LOGFILE "Past LogAttack.\n";
> }
> ================
>
> Both the pre & post call log entries show up in my general log, but I
> see no indication PERL actually falls down into the LogAttack code.
>
> Now, I have various print statements to create entries in my general
> log but none of them show up, not even the first one. Nor does the
> application crash as the form returns to the browser in roughly the
> state I expect it.
>
>
> Below is the code for LogAttack
> ============================
> sub LogAttack() {
> #Subroutine to log suspected attacks.
> #Take in the cgi object, the path & attack log file, field name, &
> value
> #Format a log entry with time, date, IP of attack, type of attack,
> field name, & value and write to the Attack Log
> print LOGFILE "in LogAttack\n";

[snip]

Are the first bit of code and LogAttack compiled in the same package?
Are you running under "warnings"?

Anno

Re: PERL Skipping a Call to a Sub.

On Aug 14, 8:33 am, anno4...@radom.zrz.tu-berlin.de wrote:
> framness wrote in comp.lang.perl.misc:
>
>
>
> > Greetings,
>
> > I am coding up an online order entry application and its been going
> > fairly well but I have run into a roadblock on something I know is
> > going to be a head slapper. It seems unlikely but it almost appears as
> > if the call to LogAttack is being skipped over. Can you spot anything
> > wrong?
>
> > I have the following code snippet:
> > ================
> > my $TextFieldValue = $SubFields->param($FieldName);
> > my $SubmittingIP = $SubFields->param('ip');
> > if(CSSAttack($TextFieldValue)) {
> > print LOGFILE "about to log attack.\n";
> > LogAttack($SubmittingIP, $AttackLogFile, "CSS Attack",
> > $FieldName, $TextFieldValue);
> > print LOGFILE "Past LogAttack.\n";
> > }
> > ================
>
> > Both the pre & post call log entries show up in my general log, but I
> > see no indication PERL actually falls down into the LogAttack code.
>
> > Now, I have various print statements to create entries in my general
> > log but none of them show up, not even the first one. Nor does the
> > application crash as the form returns to the browser in roughly the
> > state I expect it.
>
> > Below is the code for LogAttack
> > ============================
> > sub LogAttack() {
> > #Subroutine to log suspected attacks.
> > #Take in the cgi object, the path & attack log file, field name, &
> > value
> > #Format a log entry with time, date, IP of attack, type of attack,
> > field name, & value and write to the Attack Log
> > print LOGFILE "in LogAttack\n";
>
> [snip]
>
> Are the first bit of code and LogAttack compiled in the same package?
> Are you running under "warnings"?
>
> Anno

Yes, they are in the same package and no I am not running with
warnings. How would do that with a cgi?

Re: PERL Skipping a Call to a Sub.

framness writes:

> no I am not running with warnings.

Why not? Perl's quite helpful - unless you tell it not to be, which is
what you're doing.

> How would do that with a cgi?

Same as in any other script:

use strict;
use warnings;

sherm--

--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net

Re: PERL Skipping a Call to a Sub.

framness wrote in comp.lang.perl.misc:
> On Aug 14, 8:33 am, anno4...@radom.zrz.tu-berlin.de wrote:
> > framness wrote in comp.lang.perl.misc:
> >
> >
> >
> > > Greetings,
> >
> > > I am coding up an online order entry application and its been going
> > > fairly well but I have run into a roadblock on something I know is
> > > going to be a head slapper. It seems unlikely but it almost appears as
> > > if the call to LogAttack is being skipped over. Can you spot anything
> > > wrong?
> >
> > > I have the following code snippet:
> > > ================
> > > my $TextFieldValue = $SubFields->param($FieldName);
> > > my $SubmittingIP = $SubFields->param('ip');
> > > if(CSSAttack($TextFieldValue)) {
> > > print LOGFILE "about to log attack.\n";
> > > LogAttack($SubmittingIP, $AttackLogFile, "CSS Attack",
> > > $FieldName, $TextFieldValue);
> > > print LOGFILE "Past LogAttack.\n";
> > > }
> > > ================
> >
> > > Both the pre & post call log entries show up in my general log, but I
> > > see no indication PERL actually falls down into the LogAttack code.
> >
> > > Now, I have various print statements to create entries in my general
> > > log but none of them show up, not even the first one. Nor does the
> > > application crash as the form returns to the browser in roughly the
> > > state I expect it.
> >
> > > Below is the code for LogAttack
> > > ============================
> > > sub LogAttack() {
> > > #Subroutine to log suspected attacks.
> > > #Take in the cgi object, the path & attack log file, field name, &
> > > value
> > > #Format a log entry with time, date, IP of attack, type of attack,
> > > field name, & value and write to the Attack Log
> > > print LOGFILE "in LogAttack\n";
> >
> > [snip]
> >
> > Are the first bit of code and LogAttack compiled in the same package?
> > Are you running under "warnings"?
> >
> > Anno
>
> Yes, they are in the same package and no I am not running with

Okay. Otherwise the filehandles 'LOGFILE' would have been different
handles, explaining the effect you are seeing.

> warnings. How would do that with a cgi?

It works in a CGI script like in any other. Put "use warnings" early
in the code.

Anno

Re: PERL Skipping a Call to a Sub.

On Aug 14, 11:52 am, anno4...@radom.zrz.tu-berlin.de wrote:
> framness wrote in comp.lang.perl.misc:
> > On Aug 14, 8:33 am, anno4...@radom.zrz.tu-berlin.de wrote:

> > > Are you running under "warnings"?

> > no I am not running with warnings. How would do that with
> > a cgi?
>
> It works in a CGI script like in any other. Put "use
> warnings" early in the code.

I'm wagging my finger at both Sherm and Anno, who gave a technically
correct answer to this question, while (I'm assuming) knowing that
that's really not what the OP meant.

To the OP: After enabling warnings in your code as both Sherm and Anno
said, you will need to either:
(1) Look in your web server's error log. That is where the warnings
will go, because that is where STDERR has been redirected.
(2) add the following lines to your script, and then view the source
of the output, as they will cause warnings to be printed as HTML
comments (and thus not actually seen by the browser):
use CGI::Carp qw/fatalsToBrowser warningsToBrowser/;
#whatever setup you need before printing the header...
print header();
warningsToBrowser(1);

You need to not "turn on" warningsToBrowser until after you've printed
the header, so as to not interphere with the HTTP response status
line. Perl will queue up any warnings that are generated, and then
print them all as HTML comments once you've turned on this feature
with the warningsToBrowser(1) line.

Paul Lalli

Re: PERL Skipping a Call to a Sub.

On Aug 14, 11:45 am, Paul Lalli wrote:
> On Aug 14, 11:52 am, anno4...@radom.zrz.tu-berlin.de wrote:
>
> > framness wrote in comp.lang.perl.misc:
> > > On Aug 14, 8:33 am, anno4...@radom.zrz.tu-berlin.de wrote:
> > > > Are you running under "warnings"?
> > > no I am not running with warnings. How would do that with
> > > a cgi?
>
> > It works in a CGI script like in any other. Put "use
> > warnings" early in the code.
>
> I'm wagging my finger at both Sherm and Anno, who gave a technically
> correct answer to this question, while (I'm assuming) knowing that
> that's really not what the OP meant.
>
> To the OP: After enabling warnings in your code as both Sherm and Anno
> said, you will need to either:
> (1) Look in your web server's error log. That is where the warnings
> will go, because that is where STDERR has been redirected.
> (2) add the following lines to your script, and then view the source
> of the output, as they will cause warnings to be printed as HTML
> comments (and thus not actually seen by the browser):
> use CGI::Carp qw/fatalsToBrowser warningsToBrowser/;
> #whatever setup you need before printing the header...
> print header();
> warningsToBrowser(1);
>
> You need to not "turn on" warningsToBrowser until after you've printed
> the header, so as to not interphere with the HTTP response status
> line. Perl will queue up any warnings that are generated, and then
> print them all as HTML comments once you've turned on this feature
> with the warningsToBrowser(1) line.
>
> Paul Lalli

The problem was: I had sometime ago creaeted a stub function with the
name LogAttack. I had forgotten of the stub function and created
another function and this time created it with the relevant code. PERL
was trying to execute the stub function. When you informed me PERL &
Apache place those warnings into the appropriate HTTPD error log I
tracked them down and noted the appropriate warnings. That and a
couple of other tweaks helped get it working.

Thanks
Mark