PERL Skipping a Call to a Sub.

Discussion in 'Perl Misc' started by framness, Aug 14, 2007.

  1. framness

    framness Guest

    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
     
    framness, Aug 14, 2007
    #1
    1. Advertising

  2. framness

    Joe Schaefer Guest

    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
     
    Joe Schaefer, Aug 14, 2007
    #2
    1. Advertising

  3. framness

    -berlin.de Guest

    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
     
    -berlin.de, Aug 14, 2007
    #3
  4. framness

    framness Guest

    On Aug 14, 8:33 am, -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?
     
    framness, Aug 14, 2007
    #4
  5. framness

    -berlin.de Guest

    framness <> wrote in comp.lang.perl.misc:
    > On Aug 14, 8:33 am, -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
     
    -berlin.de, Aug 14, 2007
    #5
  6. framness

    Paul Lalli Guest

    On Aug 14, 11:52 am, -berlin.de wrote:
    > framness <> wrote in comp.lang.perl.misc:
    > > On Aug 14, 8:33 am, -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
     
    Paul Lalli, Aug 14, 2007
    #6
  7. framness

    framness Guest

    On Aug 14, 11:45 am, Paul Lalli <> wrote:
    > On Aug 14, 11:52 am, -berlin.de wrote:
    >
    > > framness <> wrote in comp.lang.perl.misc:
    > > > On Aug 14, 8:33 am, -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
     
    framness, Aug 15, 2007
    #7
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. THY
    Replies:
    1
    Views:
    397
    Steve C. Orr, MCSD
    Aug 19, 2003
  2. Kathy Burke
    Replies:
    3
    Views:
    397
    Kathy Burke
    Nov 24, 2003
  3. Ben
    Replies:
    2
    Views:
    898
  4. Lawrence D'Oliveiro

    Death To Sub-Sub-Sub-Directories!

    Lawrence D'Oliveiro, May 5, 2011, in forum: Java
    Replies:
    92
    Views:
    2,043
    Lawrence D'Oliveiro
    May 20, 2011
  5. bernd
    Replies:
    2
    Views:
    92
Loading...

Share This Page