You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Issac Goldstand <ne...@writeme.com> on 2001/03/14 16:00:19 UTC
Varaible scope & memory under mod_perl
I have a module that I built on my own to handle user authentication. At the moment, every perl script that I have calls a method in this module using a cookie (Supplied by browser) as an argument. Eventually I want to turn this into a mod_perl handler which instead of returning the autherized user information (in a scalar called $uid) will add a key to $ENV containing the authorized user id.
However, for the moment I have trouble in that the $uid variables (or possibly the $cookie variables) are being remembered between callings of the scripts. This results in unauthenticated users recieving access t incorrect accounts. (Even authenticated users get other peoples accounts occasionally).
In short, the module is called TFile::Authenticate, and it has a "use" line in my mod_perl startup script, to maximize persistance and minimize compile/load time. Additionally, each cgi script (for they are still all scripts) "use"s the module.
Basically, the common authorization code in each script looks something like this:
my $q=new CGI;
my $cookid=$q->cookie('sessionlid');
if (!(defined($cookid))) {print "Location: /login.html\r\n\r\n";exit;}
my $uid=eval 'check_auth($cookid);';
#The above line calls the authentication script which will return a valid $uid or undef if not valid
if (!(defined($uid))) {print "Location: /login.html\r\n\r\n";exit;}
my $cookie=$q->cookie(-name=>"sessionlid",-value=>$cookid,-expires=>expdate_auth($cookid));
The scripts then proceed to do their work and when they return content, contain the command
print STDOUT "Set-Cookie: $cookie\r\n";
Now I _know_ that some of the variables are being persistant, because when doing a telnet localhost 80, and requesting a script, I actually got a response including a cookie for a valid authentication. Now, I'm still really not sure about how the persistance works, so I suppose I could just do something like:
my $uid=undef;
my $cookid=undef;
my $cookie=undef;
...
If I include that at the beginning of all of the scripts, it could work, but it seems to me to be a bit messy; I'm sure there's a better way.
Additionally, can anyone think of a better way to add a handler to the existing TFile::Authenticate module for mod_perl scripts, while leaving the public interfaces open for normal CGI (or any other) scripts?
Thanks,
Issac
Internet is a wonderful mechanism for making a fool of
yourself in front of a very large audience.
--Anonymous
Moving the mouse won't get you into trouble... Clicking it might.
--Anonymous
PGP Key 0xE0FA561B - Fingerprint:
7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
RE: [OT] unsubscribing was Re: Varaible scope & memory under mod_perl
Posted by Ask Bjoern Hansen <as...@valueclick.com>.
On Wed, 14 Mar 2001, Steven Zhu wrote:
[...]
> another user (having different user email account). Now I got those emails
> from the alias of my original account. If I just send mail to
> modperl-unsubscribe@apache.org, I believe that it does not help because [...]
well, you could at least have tried.
then the friendly mailinglist manager would have replied back within
seconds with this message:
"To see what address you used to subscribe, look at the messages you
are receiving from the mailing list. Each message has your address
hidden inside its return path; for example, mary@xdd.ff.com receives
messages with return path: <modperl-return-<number>-mary=xdd.ff.com@apache.org."
and just to make it really easy the message would also have included
specific, easy to follow instructions on how to unsubscribe an
alternate address.
Cool, huh?
- ask (the slightly sarcastic assistant to the friendly mailinglist
manager).
--
ask bjoern hansen, http://ask.netcetera.dk/ !try; do();
RE: [OT] unsubscribing was Re: Varaible scope & memory under mod_perl
Posted by Steven Zhu <st...@springbow.com>.
First of All, I would like to thank you all for quick responses.
This is my situation. I originally joined this list as
another user (having different user email account). Now I got those emails
from the alias of my original account. If I just send mail to
modperl-unsubscribe@apache.org, I believe that it does not help because I
never joined the list as my current email. How could I unsubscribe my
original account by my current email. Is there any way I could put my
original email
in the body or somewhere. Thanks again
-----Original Message-----
From: root@www.lssi.net [mailto:root@www.lssi.net]On Behalf Of B. Burke
Sent: Wednesday, March 14, 2001 10:21 AM
To: modperl@apache.org
Subject: [OT] unsubscribing was Re: Varaible scope & memory under
mod_perl
I really don't see the point in putting list info in the headers. The
people that
have to ask these questions usually don't have full headers turned on.
Why not put it at the bottom of each email instead of the headers like some
other lists do? It would take up the same amount of space, and it would
eliminate the 'how do I unsubscribe' and 'uuugh...see headers' emails.
Brian B.
ed phillips wrote:
> agh!
>
> check the headers!
>
> Steven Zhu wrote:
>
> > How could I unsubscribe from modperl@apache.orgThank you so
> > much.Steven.
> >
> > -----Original Message-----
> >
[OT] unsubscribing was Re: Varaible scope & memory under mod_perl
Posted by "B. Burke" <bc...@mindspring.com>.
I really don't see the point in putting list info in the headers. The people that
have to ask these questions usually don't have full headers turned on.
Why not put it at the bottom of each email instead of the headers like some
other lists do? It would take up the same amount of space, and it would
eliminate the 'how do I unsubscribe' and 'uuugh...see headers' emails.
Brian B.
ed phillips wrote:
> agh!
>
> check the headers!
>
> Steven Zhu wrote:
>
> > How could I unsubscribe from modperl@apache.orgThank you so
> > much.Steven.
> >
> > -----Original Message-----
> >
Re: Varaible scope & memory under mod_perl
Posted by ed phillips <ar...@sirius.com>.
agh!
check the headers!
Steven Zhu wrote:
> How could I unsubscribe from modperl@apache.orgThank you so
> much.Steven.
>
> -----Original Message-----
>
RE: Varaible scope & memory under mod_perl
Posted by Steven Zhu <st...@springbow.com>.
How could I unsubscribe from modperl@apache.org
Thank you so much.
Steven.
-----Original Message-----
From: Issac Goldstand [mailto:neoi@writeme.com]
Sent: Wednesday, March 14, 2001 9:00 AM
To: modperl@apache.org
Subject: Varaible scope & memory under mod_perl
I have a module that I built on my own to handle user authentication. At
the moment, every perl script that I have calls a method in this module
using a cookie (Supplied by browser) as an argument. Eventually I want to
turn this into a mod_perl handler which instead of returning the autherized
user information (in a scalar called $uid) will add a key to $ENV containing
the authorized user id.
However, for the moment I have trouble in that the $uid variables (or
possibly the $cookie variables) are being remembered between callings of the
scripts. This results in unauthenticated users recieving access t incorrect
accounts. (Even authenticated users get other peoples accounts
occasionally).
In short, the module is called TFile::Authenticate, and it has a "use"
line in my mod_perl startup script, to maximize persistance and minimize
compile/load time. Additionally, each cgi script (for they are still all
scripts) "use"s the module.
Basically, the common authorization code in each script looks something
like this:
my $q=new CGI;
my $cookid=$q->cookie('sessionlid');
if (!(defined($cookid))) {print "Location: /login.html\r\n\r\n";exit;}
my $uid=eval 'check_auth($cookid);';
#The above line calls the authentication script which will return a valid
$uid or undef if not valid
if (!(defined($uid))) {print "Location: /login.html\r\n\r\n";exit;}
my
$cookie=$q->cookie(-name=>"sessionlid",-value=>$cookid,-expires=>expdate_aut
h($cookid));
The scripts then proceed to do their work and when they return content,
contain the command
print STDOUT "Set-Cookie: $cookie\r\n";
Now I _know_ that some of the variables are being persistant, because when
doing a telnet localhost 80, and requesting a script, I actually got a
response including a cookie for a valid authentication. Now, I'm still
really not sure about how the persistance works, so I suppose I could just
do something like:
my $uid=undef;
my $cookid=undef;
my $cookie=undef;
...
If I include that at the beginning of all of the scripts, it could work,
but it seems to me to be a bit messy; I'm sure there's a better way.
Additionally, can anyone think of a better way to add a handler to the
existing TFile::Authenticate module for mod_perl scripts, while leaving the
public interfaces open for normal CGI (or any other) scripts?
Thanks,
Issac
Internet is a wonderful mechanism for making a fool of
yourself in front of a very large audience.
--Anonymous
Moving the mouse won't get you into trouble... Clicking it might.
--Anonymous
PGP Key 0xE0FA561B - Fingerprint:
7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B