You are viewing a plain text version of this content. The canonical link for it is here.
Posted to asp@perl.apache.org by "John D. Leonard II" <jo...@ce.gatech.edu> on 2001/12/12 16:11:01 UTC
Bug report
Joshua (and others...):
This is difficult bug to describe, but appears to relate to the
initialization of the $Request->ServerVariables object.
I have the following OnStart event defined in my global.asa:
sub Script_OnStart{
foreach my $key (qw( REMOTE_USER REMOTE_GROUPS REDIRECT_REMOTE_GROUPS) ){
$Session->{$key} = $Request->ServerVariables($key) if
($Request->ServerVariables($key) ne "");
}
}
The purpose of this script is to set up a "sticky" REMOTE_GROUP and
REMOTE_USER login. I ask users to visit a /membersonly directory, which
uses Apache::DBI to authenticate and authorize the user. The authentication
info gets stored into the REMOTE_USER and REMOTE_GROUPS server variables.
If these values are non-zero, I copy them to the $Session for use by my
other scripts. In this manner, my ASP scripts can display different
information to users, depending on whether they are logged in, and what
their site permissions happen to be.
REMOTE_GROUP and REMOTE_USER variables should only appear in
$Request->ServerVariables when a file in one of the protected directories is
accessed. These values should be empty when accessing a non-protected file.
--> BUG: When I comment out the "foreach" transfer in the "OnStart" script
above, $Request->ServerVariables returns the correct values (i.e.,
REMOTE_GROUP and REMOTE_USER values don't exist.) HOWEVER, when the loop is
executed in "OnStart", the REMOTE_USER and REMOTE_GROUPS keys appear, and
assume the last known values (even from a different session!)
It appears that the act of referencing a non-existent key (e.g.,
REMOTE_GROUPS) in the $Request->ServerVariables object, forces the server to
return an incorrect value. I noticed this behavior on my Win32 apache
server, but have yet tested this behavior on a unix box.
Does $Request->ServerVariables keep a "local" copy of the %ENV? Could there
be something funny in the Win32 implementation (garbage collection, for
example) that would cause a old piece of hash memory to be accessed?
Does anyone see anything grossly incorrect? Is there a better way to
achieve my goals?
Here is my server setup:
Server Software: Apache/1.3.22 (Win32) mod_perl/1.26_01-dev
Apache::ASP: 2.29
Perl: 5.6.1 (ActiveState build 630)
Thanks,
JL
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: Bug report
Posted by Joshua Chamas <jo...@chamas.com>.
"John D. Leonard II" wrote:
>
> In order to make AuthDBI work on Win32, I had to remove all references to
> the IPC::SysV calls. Attached is my modified AuthDBI.pm.
>
> I believe that problem lies with the caching logic within AuthDBI, but I
> haven't tracked it down yet. I believe that the cache is disabled in the
> attached code.
>
I would at least let the author of the module know about these
things: Edmund Mergl <E.Mergl at bawue dot de> ... maybe even the mod_perl
list if Edmund is unresponsive privately.
--Josh
_________________________________________________________________
Joshua Chamas Chamas Enterprises Inc.
NodeWorks Founder Huntington Beach, CA USA
http://www.nodeworks.com 1-714-625-4051
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
RE: Bug report
Posted by "John D. Leonard II" <jo...@ce.gatech.edu>.
Joshua;
> I would not necessarily use $Session for this however, but create
> an alias to these vars like:
>
> use vars qw($Env);
> sub Script_OnStart {
> $Env = $Request->ServerVariables;
> }
Actually, I do want these data to persist between requests. My goal is to
retain the REMOTE_GROUPS variable set by AuthDBI and use it by unprotected
pages to provide different views, depending on the REMOTE_GROUPS
permissions.
> Let me know if you continue to think there is a real bug here
> and we'll get to the bottom of it.
Actually, I do think that there is a bug. However, it is NOT with Apache
nor Apache::ASP. After several tests, my session On_Start event, and
session variables all appear to work properly across sessions.
The problem only appears AFTER I perform an authentication and authorization
using Apache::DBI. After I authenticate, the REMOTE_GROUPS and REMOTE_USER
(but NOT the REMOTE_GROUP) are ALWAYS set to the last user's information,
regardless of the session. That is, even after closing the browser and
opening the browser again, the last REMOTE_GROUPS and REMOTE_USERS (or
REDIRECT_REMOTE_GROUPS) variables are set to the last values. This is a
naughty security hole.
In order to make AuthDBI work on Win32, I had to remove all references to
the IPC::SysV calls. Attached is my modified AuthDBI.pm.
I believe that problem lies with the caching logic within AuthDBI, but I
haven't tracked it down yet. I believe that the cache is disabled in the
attached code.
JL
Re: Bug report
Posted by Joshua Chamas <jo...@chamas.com>.
"John D. Leonard II" wrote:
>
> Joshua (and others...):
>
> This is difficult bug to describe, but appears to relate to the
> initialization of the $Request->ServerVariables object.
>
> I have the following OnStart event defined in my global.asa:
>
> sub Script_OnStart{
> foreach my $key (qw( REMOTE_USER REMOTE_GROUPS REDIRECT_REMOTE_GROUPS) ){
> $Session->{$key} = $Request->ServerVariables($key) if
> ($Request->ServerVariables($key) ne "");
> }
>From your description of the problem, I would probably write your
code like this:
sub Script_OnStart{
foreach my $key (qw( REMOTE_USER REMOTE_GROUPS REDIRECT_REMOTE_GROUPS) ){
$Session->{$key} = $Request->ServerVariables($key);
}
}
because the REMOTE_* keys should always be set outside of Apache::ASP.
You said you just wanted to copy them into $Session for reuse in other
parts of your application.
Because your code would use old session info even if there was no
REMOTE_* data, what you see as a core system bug might just be
a programming one in this case.
I would not necessarily use $Session for this however, but create
an alias to these vars like:
use vars qw($Env);
sub Script_OnStart {
$Env = $Request->ServerVariables;
}
or I might create a special $Auth object/hash for this data for
easy referencing later. Use $Session only when you need data
to persist in a transparent way from one request to another.
If the data is already in auth headers being sent by the client,
then you can init this per request, and not take the performance
hit of using $Session to store this data ( memory vs. disk storage )
Let me know if you continue to think there is a real bug here
and we'll get to the bottom of it.
--Josh
_________________________________________________________________
Joshua Chamas Chamas Enterprises Inc.
NodeWorks Founder Huntington Beach, CA USA
http://www.nodeworks.com 1-714-625-4051
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org