You are viewing a plain text version of this content. The canonical link for it is here.
Posted to asp@perl.apache.org by Brat Wizard <br...@naxs.com> on 2001/12/09 13:25:55 UTC
Using Apache::ASP with offline scripts- HOW???
Howdy-
I'm wondering if there is a neat and clever way to utilize the functionality of
Apache::ASP in an offline capacity...
This isn't as hair-brained a request as it might seem-- I am attempting to
create a background processor script to dig through a database and send
html-formatted email to appropriate folks. So it is an html-related thing, its
just that apache isn't involved ;)
I would very much like it if I could "think" in Apache::ASP style as I write my
background processes as they are much more html than they are anything else-
they just happen to take place offline and are scheduled by cron.
Is this possible??
Thanks
John Whitten
brat@naxs.com
---------------------------------------------------------------------
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
Bug report
Posted by "John D. Leonard II" <jo...@ce.gatech.edu>.
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: Undefined subroutine &Apache::ASP::handler called.
Posted by Joshua Chamas <jo...@chamas.com>.
Dariusz Pietrzak wrote:
>
> > Sounds like the kind of bug that would occur to a DSO build
> > of mod_perl + apache, use of Apache::StatINC or use of Apache::Reload.
> The next day problem dissapeared so I am having problems with locating the
> cause now - maybe there was sth wrong with the system, I couldn't locate
> it though.
>
> This was not on DSO build as I said, strange thing is that it works with
> both apache-perl and apache + DSO mod_perl ( and this is the first time
> DSO mod_perl works for Apache::ASP for me, now I changed my home system
> from static to DSO and it works. )
> It is said in FAQ/webpage that DSO build would randomly fail - until now
> DSO builds have ALWAYS failed me, and now they are working OK.
> Has something changed in mod_perl as DSO status?
>
I think Doug & others attempt patches to make DSO behave better from
time to time, but I don't know that anyone has ever figured out why
DSO configurations behave so chaotically. Some swear by them, and
generally if it works, I won't ask why. If it doesn't I won't ask
why not either, I usually just compile a static apache/mod_perl anyway.
-- 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: Undefined subroutine &Apache::ASP::handler called.
Posted by Dariusz Pietrzak <da...@ajax.umcs.lublin.pl>.
> Sounds like the kind of bug that would occur to a DSO build
> of mod_perl + apache, use of Apache::StatINC or use of Apache::Reload.
The next day problem dissapeared so I am having problems with locating the
cause now - maybe there was sth wrong with the system, I couldn't locate
it though.
This was not on DSO build as I said, strange thing is that it works with
both apache-perl and apache + DSO mod_perl ( and this is the first time
DSO mod_perl works for Apache::ASP for me, now I changed my home system
from static to DSO and it works. )
It is said in FAQ/webpage that DSO build would randomly fail - until now
DSO builds have ALWAYS failed me, and now they are working OK.
Has something changed in mod_perl as DSO status?
> be interested in hearing what seems to make this problem go away!
I think this was my fault - missconfiguration problem. Just didn't figured
what exactly did I do wrong.
Sorry for this thread.
--
Dariusz Pietrzak
snafu
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: Undefined subroutine &Apache::ASP::handler called.
Posted by Joshua Chamas <jo...@chamas.com>.
Dariusz Pietrzak wrote:
>
> Ehlo,
> I need help with tracking down this error, it occurs randomly -
> everything works fine.. then I get 'internal server...' with error
> mentioned above.. refresh.. and everything works fine again.
> this is very fresh install of debian woody, and I haven't run apache::asp
> on new machine for a long time, so maybe i'm just missing something.
> This is without PerlRequire, so no modules are loaded..
>
Hey Dariusz,
Sounds like the kind of bug that would occur to a DSO build
of mod_perl + apache, use of Apache::StatINC or use of Apache::Reload.
I would make sure to do "PerlModule Apache::ASP" in your httpd.conf
for good measure, though this should not be necessary. I would
be interested in hearing what seems to make this problem go away!
--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
Undefined subroutine &Apache::ASP::handler called.
Posted by Dariusz Pietrzak <da...@ajax.umcs.lublin.pl>.
Ehlo,
I need help with tracking down this error, it occurs randomly -
everything works fine.. then I get 'internal server...' with error
mentioned above.. refresh.. and everything works fine again.
this is very fresh install of debian woody, and I haven't run apache::asp
on new machine for a long time, so maybe i'm just missing something.
This is without PerlRequire, so no modules are loaded..
--
Dariusz Pietrzak
snafu
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: Using Apache::ASP with offline scripts- HOW???
Posted by Joshua Chamas <jo...@chamas.com>.
Dariusz Pietrzak wrote:
>
> > I'm wondering if there is a neat and clever way to utilize the functionality of
> > Apache::ASP in an offline capacity...
> how about 'asp' script,
> i think it's included in Apache::ASP distribution
>
> eyck@ghost:~$ asp
>
Exactly... the asp script is at ./cgi/asp in the distribution.
-- Josh
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: Using Apache::ASP with offline scripts- HOW???
Posted by Dariusz Pietrzak <da...@ajax.umcs.lublin.pl>.
> I'm wondering if there is a neat and clever way to utilize the functionality of
> Apache::ASP in an offline capacity...
how about 'asp' script,
i think it's included in Apache::ASP distribution
eyck@ghost:~$ asp
Usage: asp [-hsdb] [-o directory] file1 @arguments file2 @arguments ...
-h Help you are getting now!
-s Setup $Session and $Application state for script.
-d Set to debug code upon errors.
-b Only return body of document, no headers.
-o Output directory, writes to files there instead of STDOUT
This program will run asp scripts from the command line.
Each file that is specified will be run, and the
$Request->QueryString() and $Request->Form() data will
be initialized by the @arguments following the script file
name. The @arguments will be written as space separated
words, and will be initialized as an associate array where
%arguments = @arguments.
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
RE: Using Apache::ASP with offline scripts- HOW???
Posted by "John D. Leonard II" <jo...@ce.gatech.edu>.
John:
The beauty of Apache::ASP is that it is all written in "perl". I often
implement the off-line functionality that you describe through a "cron" job
and a perl script (or a makefile.) See the LWP library (to pull data from
other web sites,) the DBI library (to pull data from local data bases,) and
perhaps the CGI library (to create your HTML outputs.)
If you want to share code between your CRON scripts and your Apache::ASP
applications, then you can create your own perl modules (.pm files.) Then,
either your perl scripts or Apache::ASP applications can "use mymodule;" and
access the same perl subs.
JL
> -----Original Message-----
> From: root@mail02.cavtel.net [mailto:root@mail02.cavtel.net]On Behalf Of
> Brat Wizard
> Sent: Sunday, December 09, 2001 7:26 AM
> To: ASP Mailing List
> Subject: Using Apache::ASP with offline scripts- HOW???
>
>
>
>
> Howdy-
>
> I'm wondering if there is a neat and clever way to utilize the
> functionality of
> Apache::ASP in an offline capacity...
>
> This isn't as hair-brained a request as it might seem-- I am attempting to
> create a background processor script to dig through a database and send
> html-formatted email to appropriate folks. So it is an
> html-related thing, its
> just that apache isn't involved ;)
>
> I would very much like it if I could "think" in Apache::ASP style
> as I write my
> background processes as they are much more html than they are
> anything else-
> they just happen to take place offline and are scheduled by cron.
>
> Is this possible??
>
> Thanks
>
> John Whitten
> brat@naxs.com
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
> For additional commands, e-mail: asp-help@perl.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org