"use CGI " hangs "CGI time out "

G

GMI

I am writing a simple login program to get a ID and Password check agains a
MySQL database , send a cookie.

when these 2 line added :
use CGI;
$Query = new CGI;

The program, it hangs and after a long time system comes with a CGI time
out error?
in DOS mode however the routine works fine.
Can someone out there help?
-----------------------------------
here is part of the code
---------------------

#Login process for NOYQ
require "subparseform.lib";
use CGI;
$Query = new CGI;
my $ErrMsg,$ErrNo=0, $ID ;
my $PassWord,$fName,$lName;
my $Dte_Lst,$Cookie;
($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst)=localtime(time);
$mon=$mon+1;
$year=$year+1900;
$Date = "$year-$mon-$mday $hour:$min:$sec" ;
Parse_Form();
NOinitFrm();
$ID='***';$PassWord='******',$Continue='Continue';
#
if ($Continue ne "Continue")
{
# this is the initial run (Not continue & not Cancel)
$LgNo =1;
$ErrMsg='';
#Just print the form and exit
NoClPrnFrm();
exit
};
$ErrMsg='';
if($ID le '' ) {
$ErrNo++;
$ErrMsg="$ErrMsg $ErrNo - Please enter a valid ID";
}
elsif(! DB_Connect())
{$ErrNo++; $ErrMsg="$ErrMsg $ErrNo- Failed to Connect to SQL server."
}

elsif (! CheckPW($ID,$PassWord))
{ $ErrNo++;
$ErrMsg= "$ErrMsg $ErrNo- Password or ID invalid! $ID,$PW $SqlString ";
}
elsif(! NORecDte())
{ $ErrNo++;
$ErrMsg="$ErrMsg $ErrNo- Could not Update Login! "
};


if ($ErrNo = 0) {
SendCookie('NOYQSecure',$ID,'+1d','/' ,'WWW.NOYQ.ca',0) ;
print "<title>'NOYQ User Logged'</title></head>
<body> Welcome back $fName $lName. Last Login was.:$Dte_Lst <BR>
<p><a href='/' target=_top>Home</a></P> '
</body>
</html>
";
exit
};

------------------------------------------------
HERE IS THE DOS COMMAND OUTPUT...........
c:>Perl No-logi1.pl
---------
Content-type: text/html

<P>Use Post or GetSet-Cookie: NOYQSecure=bazil; domain=WWW.NOYQ.ca; path=/;
expires=Tue, 21-Jun-2005 13:56:21 GMT
Date: Mon, 20 Jun 2005 13:56:21 GMT
Content-Type: text/html; charset=ISO-8859-1

<html><head><title>'NOYQ User Logged'</title></head>
<body> Welcome back Bazil Ghassemlou. Last Login was.:2005-6-20 9:52:7
<BR>
<p><a href='/' target=_top>Home</a></P> '
</body>
</html>
 
A

A. Sinan Unur

The program, it hangs and after a long time system comes with a CGI
time out error?
in DOS mode however the routine works fine.
Click to expand...

perldoc -q 500

might help when you encounter this type of situation. However, see my
specific comments below:
#Login process for NOYQ
require "subparseform.lib";
Click to expand...

This is probably some crappy cargo cult CGI processing thingy: Dump it.
use CGI;
$Query = new CGI;
Click to expand...

You should have

use strict;
use warnings;

in your code.

This seems to be a good time for you to peruse the posting guidelines
for this group: They contain invaluable information on how you can help
yourself, and help others help you.
my $ErrMsg,$ErrNo=0, $ID ;
my $PassWord,$fName,$lName;
Click to expand...

You should always declare variables in the smallest applicable scope,
and name them so they are readable.
my $Dte_Lst,$Cookie;
($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst)=localtime(time);
$mon=$mon+1;
$year=$year+1900;
$Date = "$year-$mon-$mday $hour:$min:$sec" ;
Click to expand...

This is crazy.
Parse_Form();
Click to expand...

What's happening is that instantiating a CGI object consumes the input
coming in, there is nothing for Parse_Form to read from STDIN, so it
waits for input until the web server decides to kill it.

You have a choise to make here: Either use the crappy code, or use CGI,
not both. I think the choice is clear.

It also seems clear to me that you should read "Learning Perl".

NOinitFrm();
$ID='***';$PassWord='******',$Continue='Continue';
#
if ($Continue ne "Continue")
Click to expand...

WTF? How can this happen?
{
# this is the initial run (Not continue & not Cancel)
Click to expand...

Most of the code from this point on is fairly incomprehensible to me.

You really, really need to o back to the basics. You have just told me
how to crack my way in to www.noyq.ca. Please do not use this script for
any purpose. You need some *intensive* studying of both Perl and web
security fundamentals.

This is for your own good.

Sinan
 
B

Brian Wakem

A. Sinan Unur said:
You should always declare variables in the smallest applicable scope,
and name them so they are readable.


Sinan
Click to expand...


It's also worth pointing out that when using strict, 4 errors will occur
in the above two lines as the my only applies to the first variable in
each case.
 
A

Alfred Z. Newmane

Brian said:
It's also worth pointing out that when using strict, 4 errors will
occur in the above two lines as the my only applies to the first
variable in each case.
Click to expand...

True. I believe thats an error that cna come from spending a long time
with langs like C or C++, wher you can start with the typename and have
a comma delimited list of variables taking that type:

int a,b,c;

All that needs to be done with thw code in question is add ()'s around
the variable list:
(Also note the initialization of $ErrNo=0 had to be corrected as well.)

my ($ErrMsg, $ErrNo, $ID) = (undef, 0);
my ($PassWord, $fName, $lName);
 
A

A. Sinan Unur

True. I believe thats an error that cna come from spending a long time
with langs like C or C++, wher you can start with the typename and
have a comma delimited list of variables taking that type:

int a,b,c;
Click to expand...

How about:

int* a, b;

Sinan
 
E

Eric Bohlman

How about:

int* a, b;
Click to expand...

[now getting hopelessly OT]

I got in the habit of writing "type *v" rather than "type* v", reading it
as "the thing v points to is this type" (which, IIRC, is actually how K&R
explained it). "int *a, b;" reads to me unambiguously as "both the
thingy a points to and b are integers" without implying that b is a
pointer. The underlying concept is that pointeritude[tm] and type are
parallel attributes of a variable, rather than pointeritude being an
attribute of type, and therefore the indicator of pointeritude should be
closer to the variable name than the type name.
 
A

A. Sinan Unur

How about:

int* a, b;
Click to expand...

[now getting hopelessly OT]

I got in the habit of writing "type *v" rather than "type* v", reading
it as "the thing v points to is this type" (which, IIRC, is actually
how K&R explained it).
Click to expand...

I agree, and that's the style I use as well. However, my remark was
related to the following:

# #
#>>> #>>>
#>>>> my $ErrMsg,$ErrNo=0, $ID ;
#>>>> my $PassWord,$fName,$lName;
#
# I believe thats an error that cna come from spending a long time
# with langs like C or C++, wher you can start with the typename
# and have a comma delimited list of variables taking that type:

I was trying to point out that similar errors can be made in C as well.

Anyway, sorry for the drift.

Sinan
 
B

Bart Lateur

Eric said:
"int *a, b;" reads to me unambiguously as "both the
thingy a points to and b are integers" without implying that b is a
pointer.
Click to expand...

You've gotten used to it, then.

The you can declare both a pointer and an integer in the same combined
line is, IMHO, a major design flaw in C. Delaring an integer and a
pointer to an integer are two totally dissimilar tasks. Less similar
than declaring a double and an integer, and you can't combine those two
declarations.
 
T

Tassilo v. Parseval

Also sprach Bart Lateur:
You've gotten used to it, then.

The you can declare both a pointer and an integer in the same combined
line is, IMHO, a major design flaw in C. Delaring an integer and a
pointer to an integer are two totally dissimilar tasks. Less similar
than declaring a double and an integer, and you can't combine those two
declarations.
Click to expand...

Strictly speaking, C doesn't say: "Variable p is of type 'pointer to
int'". Instead it says: "Variable p, when dereferenced, is an int".
That's why the dereference operator is used for declaring pointers:

int *p;

Hence your analogy to declaring both a double and and int in the same
statement is not applicable. In:

int a, *p;

both 'a' and '*p' are integers.

Tassilo
 
B

Bart Lateur

Tassilo said:
Hence your analogy to declaring both a double and and int in the same
statement is not applicable. In:

int a, *p;

both 'a' and '*p' are integers.
Click to expand...

But it doesn't declare *p, it declares p. That's what it's for. *p does
actually even exist yet, as p is NULL.
 
A

Alfred Z. Newmane

A. Sinan Unur said:
How about:

int* a, b;
Click to expand...

[now getting hopelessly OT]

I got in the habit of writing "type *v" rather than "type* v",
reading it as "the thing v points to is this type" (which, IIRC, is
actually how K&R explained it).
Click to expand...

I agree, and that's the style I use as well. However, my remark was
related to the following:

# #
#>>> #>>>
#>>>> my $ErrMsg,$ErrNo=0, $ID ;
#>>>> my $PassWord,$fName,$lName;
#
# I believe thats an error that cna come from spending a long time
# with langs like C or C++, wher you can start with the typename
# and have a comma delimited list of variables taking that type:

I was trying to point out that similar errors can be made in C as
well.
Click to expand...

True.

(And I'm also sorry to add to the topicular-steller drift here, but...)

For the record, I use that style when declaring pointers as well:

type *var;

The only time I put the * next to the type-name is for function return
types:

type* somefunc() { }

As there is no var in this case. I talways made sense to me, as you are
/returning/ a pointer-to-type.

Other than that I keep the * by the var-name, when there /is/ a var-name
:)

...........

So what are some of your prefs on function return types that are
pointers? * is beside the type-name or the
function-name/calling-convention (the next token after the return type)
?
 
A

Alfred Z. Newmane

Bart said:
You've gotten used to it, then.

The you can declare both a pointer and an integer in the same combined
line is, IMHO, a major design flaw in C. Delaring an integer and a
pointer to an integer are two totally dissimilar tasks. Less similar
than declaring a double and an integer, and you can't combine those
two declarations.
Click to expand...

I disagree it's a disgn flaw.

int *p /points/ to an int, it's root type is still int, so why does it
not make sense to have a one liner like:

int n, *p;

?

What this is really saying is: I want n to be an int, and I want p to be
a pointer to an int, both of which can give an int.

An "pointer" is not a type, but more of a modifier, that affects how you
retrieve the type (making you dereference it), but it's type is still
"type" (int in this case.)

The main diference is where the value of "type" is being stored. Instead
of in the pantry (stack), it's in the warehouse (heap.) But the item
being stored is the same (type of) item.

Going with the anology, a can of beans is the same can weather you put
it in your pantry or in the warehouse :)
 
A

Alfred Z. Newmane

Tassilo said:
Also sprach Bart Lateur:


Strictly speaking, C doesn't say: "Variable p is of type 'pointer to
int'". Instead it says: "Variable p, when dereferenced, is an int".
That's why the dereference operator is used for declaring pointers:

int *p;

Hence your analogy to declaring both a double and and int in the same
statement is not applicable. In:

int a, *p;

both 'a' and '*p' are integers.
Click to expand...

Thats exactly what I was getting at. (See my post parallel to this one.)
Though I think your explanation came out better than mine :)
 
A

Alfred Z. Newmane

Bart said:
But it doesn't declare *p, it declares p. That's what it's for. *p
does actually even exist yet, as p is NULL.
Click to expand...

in c and c++ variables that are uninialized usually have a random value,
not NULL or 0 (zero.)

Someone correct me if I'm wrong, but it's the value of an uninialized
variable simply the value that was last i nthe address the new var now
occupies? (I never really thought about it like this before this
thread.)
 
A

A. Sinan Unur

Alfred said:
in c and c++ variables that are uninialized usually have a random value,
not NULL or 0 (zero.)

Someone correct me if I'm wrong,
Click to expand...

I don't think you are wrong, however, you might want to move this
discussion to comp.lang.c

Sinan
 
A

Alfred Z. Newmane

A. Sinan Unur said:
I don't think you are wrong, however, you might want to move this
discussion to comp.lang.c
Click to expand...

Thats probably a good idea.

Also, please be careful with your quoting, you cut off my sentance, thus
throwing off the context a little:

From: "Alfred Z. Newmane" <[email protected]>
Newsgroups: comp.lang.perl.misc
Subject: Re: [OT] Re: "use CGI " hangs "CGI time out "
Date: Thu, 23 Jun 2005 10:21:06 -0700
Message-ID: <[email protected]>

Bart said:
But it doesn't declare *p, it declares p. That's what it's for. *p
does actually even exist yet, as p is NULL.
Click to expand...

in c and c++ variables that are uninialized usually have a random value,
not NULL or 0 (zero.)

Someone correct me if I'm wrong, but it's the value of an uninialized
variable simply the value that was last i nthe address the new var now
occupies? (I never really thought about it like this before this
thread.)
 
A

A. Sinan Unur

Thats probably a good idea.

Also, please be careful with your quoting, you cut off my sentance,
thus throwing off the context a little:
Click to expand...

My comments were not related to your theorizing regarding the value of
an uninitialized variable. I have been trying to point out that this
topic is not appropriate for c.l.p.misc for a while now.

I am so sorry that my attempt at correcting your bogus explanation of
why the OP my the mistake of declaring variables as in

my $x, $y, $z;

has led to this to the materialization of this thread.

Please, if you want to discuss C, comp.lang.c is the place. There was no
reason to bring C into this thread (which you originally did, and which
is why I marked my response to you OT).

I have lost patience.

*PLONK*

Sinan
 
E

Eric Sosman

Clark said:
Correct.
Click to expand...

Well, partly correct. An uninitialized variable of
`auto' or `register' storage class "contains garbage" --
formally, its value is indeterminate.

Things are different, though, for variables declared
at file scope (outside any function) or for function-local
variables declared `static'. If no initializer is present,
these variables are initialized to zero or NULL before
the program starts executing. At file scope,

int i;
double d;
char *p;

is equivalent to

int i = 0;
double d = 0.0;
char *p = 0; /* NULL */
 
A

Alfred Z. Newmane

A. Sinan Unur said:
My comments were not related to your theorizing regarding the value of
an uninitialized variable. I have been trying to point out that this
topic is not appropriate for c.l.p.misc for a while now.

I am so sorry that my attempt at correcting your bogus explanation of
why the OP my the mistake of declaring variables as in

my $x, $y, $z;

has led to this to the materialization of this thread.

Please, if you want to discuss C, comp.lang.c is the place. There was
no reason to bring C into this thread (which you originally did, and
which is why I marked my response to you OT).
Click to expand...

I originally mentioned C/C++ as an example of where the OP's thinking
may have come from. It branched off from there. I did not know it was
such a heinous crime. I'm sorry, but there is nothing wrong with side
discussions, it's something that happens sometimes UseNet and even real
life conversations.

Why you need to act like you're being forced into this thread is beyond
me, as the user of a news reader can pick what they want to read, and
pass on the ones they don't like. Try it sometime.
I have lost patience.
Click to expand...

Why are you replying then?
*PLONK*
Click to expand...

And you really think anyone else with a brain and a life gives a
flipping damn?

Why are you even replying then if you don't care about it? Is it that
hard for you to just go on to other threads instead of acting like this
thread should be ignored by everyone just because /YOU/ deem it
unworthy? If so, it seems others disagree with you as there appeared to
be a good wholesome conversation going on here, involving others besides
myself.

A lot of people here have been programming for quite a while, and it's a
no-brainier that plenty of Perl programmers started in C and/or C++. The
reason I added comp.lang.c to the ng list was that I wanted to move the
discussion to the c group, but not leave out the folks in c.l.p.m who
were following it out in the cold, which to me would seem like a rude
thing to do.
 

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

Similar Threads

Login page perl/CGI 2
Login page perl/CGI 1
Ruby, CGI and HTML Forms 1
Once again: CGI help 3
Need help with code on website (noob) 2
Cookie not working for CGI logon script 1
PERL CGI Script Responding to Link 4
Converting my index.pl(cgi) to html::template one 4

Members online

No members online now.
Total: 56 (members: 0, guests: 56)
Robots: 103

Forum statistics

Threads
473,999
Messages
2,570,243
Members
46,835
Latest member
lila30

Latest Threads

Top