PERL Skipping a Call to a Sub.

F

framness

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
 
J

Joe Schaefer

framness said:
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.
 
A

anno4000

framness said:
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
 
F

framness

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?
 
A

anno4000

framness said:
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
 
P

Paul Lalli

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
 
F

framness

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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top