[mp2.0] Can't locate object method push_handlers via packageApache::RequestRec
I am a little rusty (switched to telecomm ... just doing some web work on
the side now), but my script looks okay to me. The archive and many
hours to trying different things do not seem to be helping. Has anyone
seen this before, or can you see a problem with it? TIA
System Info
===
# uname -a
Linux localhost.localdomain 2.4.18-14 #1 Wed Sep 4 13:35:50 EDT 2002 i686
i686 i386 GNU/Linux
# rpm -q mod_perl
mod_perl-1.99_05-3
# rpm -q httpd
httpd-2.0.40-8
Conf snippet
Directory /var/www/html
# This mod_perl Output filter wraps html output in the standard template
PerlOutputFilterHandler InfoMart::TemplateOutputFilter
Options Indexes FollowSymLinks
AllowOverride All
Order allow,deny
Allow from all
/Directory
Directory /var/www/html/ztest
PerlFixupHandler InfoMart::SessionFixupHandler
/Directory
SessionFixupHandler.pm
==
#!/usr/bin/perl
package InfoMart::SessionFixupHandler;
use strict vars;
use warnings;
use Apache2 ();
use Apache::RequestRec ();
use Apache::RequestIO ();
use APR::Table ();
use Apache::Const -compile = 'OK';
use CGI::Cookie;
#use Apache::Session::Postgres;
sub handler {
my $r = shift;
my $table = $r-headers_in();
my $cookies = parse CGI::Cookie($table-get(Cookie));
my $sessionID = ($cookies $cookies-{'sessionID'} ?
$cookies-{'sessionID'}-value : undef);
#TODO: validate the sessionID. set $sessionID to undef if invalid
if (!defined($sessionID)) {
$r-handler('modperl');
$r-push_handlers(PerlResponseHandler = sub {set_cookie});
} else {
$r-notes-set(sessionID = $sessionID);
#my %session;
#tie %session, Apache::Session::Postgres, $sessionID, {
# DataSource = 'dbi:Pg:dbname=sessions',
# Commit = 1
#};
#$session{foo}=bar;
#$r-notes-set('session' = \%session);
}
return Apache::OK;
}
sub set_cookie {
my $r = shift;
# my %session;
# tie %session, Apache::Session::Postgres, undef, {
#DataSource = 'dbi:Pg:dbname=sessions',
#Commit = 1
# };
my $sessionID = 'foo';
# my $sessionID = $session{_session_id};
my $cookie = CGI::cookie(-name=sessionID,
-value=$sessionID,
-expires=+1h,
-path=/,
-domain=www.miabusinc.com,
);
$r-err_headers_out-add('Set-Cookie' = $cookie);
$r-headers_out-set(Location =
http://www.miabusinc.com/cgi-bin/cookie_check.cgi?src=;.($r-uri));
$r-status(302);
$r-send_http_header;
return Apache::OK;
}
1;
Error
=
[Sun Feb 23 21:26:07 2003] [error] [client 12.236.181.139] Can't locate
object method push_handlers via package Apache::RequestRec at
/usr/lib/perl5/site_perl/5.8.0/InfoMart/SessionFixupHandler.pm line 33.
Re: [mp2.0] Can't locate object method push_handlers via packageApache::RequestRec
Eric A. Zarko wrote: I am a little rusty (switched to telecomm ... just doing some web work on the side now), but my script looks okay to me. The archive and many hours to trying different things do not seem to be helping. Has anyone seen this before, or can you see a problem with it? TIA [...] [Sun Feb 23 21:26:07 2003] [error] [client 12.236.181.139] Can't locate object method push_handlers via package Apache::RequestRec at /usr/lib/perl5/site_perl/5.8.0/InfoMart/SessionFixupHandler.pm line 33. You simply haven't loaded the module which contains this method. I use the following helper alias: % lookup push_handlers There is more than one class with method 'push_handlers' try one of: use Apache::ServerUtil (); use Apache::RequestUtil (); For more info see: http://perl.apache.org/docs/2.0/api/ModPerl/MethodLookup.html though you will need to build the cvs version of mod_perl to get this functionality. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
[mp2] make test errors w/. threadmutex, push_handlers
Hi all, Using the very latest cvs sources, make test failed with the following: [ ... ] apr/pool.ok apr/string...ok apr/tableok apr/threadmutex..FAILED tests 1-3 Failed 3/3 tests, 0.00% okay apr/util.ok apr/uuid.ok compat/apacheok compat/apache_file...ok compat/apache_table..ok compat/apache_util...ok compat/request...ok compat/request_body..ok compat/send_fd...ok directive/envok directive/perl...ok directive/perldo.ok directive/perlloadmodule.ok directive/perlloadmodule2ok directive/perlloadmodule3ok directive/perlloadmodule4ok directive/perlloadmodule5ok directive/perlloadmodule6ok directive/perlmodule.ok directive/perlrequireok directive/podok directive/setupenv...ok error/push_handlers..# Failed test 1 in error/push_handlers.t at line 14 error/push_handlers..FAILED test 1 Failed 1/1 tests, 0.00% okay filter/in_bbs_body...ok filter/in_bbs_msgok filter/in_str_consumeok filter/in_str_lc.ok filter/in_str_msgok filter/in_str_sandwich...ok filter/out_bbs_basic.ok filter/out_bbs_ctx...ok filter/out_str_api...ok filter/out_str_ctx...ok filter/out_str_lcok filter/out_str_reverse...ok hooks/access.ok hooks/authen.ok hooks/authz..ok hooks/fixup..ok hooks/headerparser...ok hooks/init...ok hooks/trans..ok modperl/dir_config...ok modperl/endavok modperl/env..ok modperl/exit.ok modperl/getc.ok modperl/method...ok modperl/methodname...ok modperl/methodobjok modperl/pnotes...ok modperl/printok modperl/printf...ok modperl/readline.ok modperl/sameinterp...ok modperl/setauth..ok modperl/subenv...ok
Not a subroutine name... (was Re: problem with $r-push_handlers())
mod_perl_push_handlers: Not a subroutine name or CODE reference!
I have observed similar problem myself. I got the same error when I
wrote in my startup.pl
Apache-push_handlers(PerlChildInitHandler,
\MyApp::Main::on_child_init);
when I replaced it with
Apache-push_handlers(PerlChildInitHandler,
sub { MyApp::Main::on_child_init(); });
it works as expected.
It is probably worth noting, that in my opinion the first syntax
should work and there is something wrong in mod_perl code...
Is it something 'well known' or 'by design'?
Re: problem with $r-push_handlers()
I have traced my problem to the following
subroutine which populates the Hash I use to keep track of mappings of URL's to
Modules (handlers)to use.
As you will see, at the very end of my parse_file
subroutine I have two lines commented out. IF I uncomment these lines out, I end
up overwriting the data in my hash with the clean data I supply. When I do this
my Apache Multiplexer (the thing which does the
$r-push_handlers($handler_bf)) works fine and all is fine. However if I
leave the line commented out - as is here - I get the following
error:-
[Tue Sep 17 22:41:35 2002] [error] Undefined
subroutine MyMod::Apache::Test1 called, GEN2 line 2.
So I'm at a loss, any further help you could give
would be useful,
Marty
Here is a sample file:-
/test1/ =
MyMod::Apache::Test1/test2/ =
MyMod::Apache::Test2
Here is a file parsing subroutine I use to read the
above file and populate a hash, which I export to another
routine.:-
our (%HANDLERS);
sub _is_tainted{ not eval {
join("",@_), kill 0; 1; };}
sub parse_file{ my
$file=shift; print STDERR "Parsing file $file\n"; open
(FILE,"$file") or die "Cannot open file for reading $file"; while
(my $line=FILE) { chomp
$line; if ($line=~/^\#/)
{ next;
} else
{ my
($keyname,$varname)=split/\=/,$line; print
STDERR "Initial $keyname = $varname\n";
$keyname=~s/^\s*//;
$varname=~s/^\s*//;
$keyname=~s/\s*$//;
$varname=~s/\s*$//;
$keyname=~s/'//g;
$varname=~s/'//g;
$keyname=~s/"//g;
$varname=~s/"//g;
$keyname=~s/^\///;
$keyname=~s/\/$//; my @tmp=split /\//,
$keyname; my
$untainted_keyname; while
(@tmp)
{ my $tainted_var=shift
@tmp; if ($tainted_var
=~/^([\w-]+)$/)
{
$tainted_var=$1; die
"$tainted_var is Tainted" if
(_is_tainted($tainted_var));
$untainted_keyname.='/'.$tainted_var;
die "$untainted_keyname is Tainted" if
(_is_tainted($untainted_keyname));
}
else
{ die "Taint Check
failed for $tainted_var\n";
} }
$untainted_keyname.='/'; if
($varname=~/^([-:\w]+)$/)
{
$varname=$1; die "$varname is
Tainted" if (_is_tainted($varname));
} else
{ die "Taint Check failed for
$varname\n";
}
$HANDLERS{$untainted_keyname}=$varname; print
STDERR "Added $keyname = $varname\n"; }
} #$HANDLERS{'/test1/'}='MyMod::Apache::Test1';
#$HANDLERS{'/test2/'} = 'MyMod::Apache::Test2'; close
(FILE);}
- Original Message -
From:
Martin Moss
To: [EMAIL PROTECTED]
Sent: Tuesday, September 17, 2002 2:13
AM
Subject: problem with
$r-push_handlers()
All,
can anybody provide any help with this
problem - and maybe explain why I get the following
anomoly?
I've been trying to find the cause of the issue
but to no avail:-(
I have MyMod::Apache::Test pre-loaded in my httpd.conf file.
Here is an extract of code:-
($handler is defined from a Hash defined within
this Code)
($handler_bf is defined from a hash exported by a
module used in this code. to get to the stage in the code where the following
lines commence, I already have read the value from the exported hash and it is
held in the variable $handler_bf)
#$r-push_handlers(PerlHandler =
$handler);$r-push_handlers(PerlHandler =
$handler_bf);
print STDERR "They match\n ($handler) = ($handler_bf)\n" if ($handler
eq $handler_bf);
When I run the code I get the following error:-
MyMod::Apache::Multiplex Matched /test/ to MyMod::Apache::Test
(MyMod::Apache::Test) for /mod_perl_push_handlers: Not a subroutine name
or CODE reference! at /usr/local/lib/perl//MyMod/Apache/Multiplex.pm line
101.They match(MyMod::Apache::Test) =
(MyMod::Apache::Test)
WHEREAS if I use the following code:-
#$r-push_handlers(PerlHandler =
$handler);$r-push_handlers(PerlHandler =
$handler_bf);
print STDERR "They match\n ($handler) = ($handler_bf)\n" if ($handler
eq $handler_bf);
It works and I get this output :-
MyMod::Apache::Multiplex Matched /reconciler/test/ to MyMod::Apache::Test
(MyMod::Apache::Test) for /They match(MyMod::Apache::Test) =
(MyMod::Apache::Test)
So I'm still at a loss. I've tried checking for tainted variables as the
handler hash which fails is populated by reading the contents of files,
whereas the other is simply defined in the script.
I'm guessing this is something more subtle like a configuration
problem.
I've tried stopping a starting apache after making each change to the
script. so each test is run on a fresh server.
Anyway, Answers on a Postcard please:-)
Regards
Marty
Re: problem with $r-push_handlers()
You are a star!!!
I ammended your syntax slightly
and did this:-
my $sub_string='sub { '.$handler_bf.'($r) };';
$r-push_handlers(PerlHandler = eval $sub_string);
Otherwise The handler routine of my handler module doesn't get passed the
Apache object as it's first argument.
It seems to work fine. Thank you.
One point to ask, Is this less efficient, as I'm passing an anonynmous
subroutine around rather than a code reference?
I can finally go to bed :-)
Kind regards
Marty
- Original Message -
From: Marcin Kasperski [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, September 18, 2002 12:55 AM
Subject: Re: problem with $r-push_handlers()
MyMod::Apache::Multiplex Matched /test/ to MyMod::Apache::Test
(MyMod::Apache::Test) for /
mod_perl_push_handlers: Not a subroutine name or CODE reference! at
/usr/local/lib/perl//MyMod/Apache/Multiplex.pm line 101.
They match
(MyMod::Apache::Test) = (MyMod::Apache::Test)
I have observed similar problem myself. I got the same error when I
wrote in my startup.pl
Apache-push_handlers(PerlChildInitHandler,
\MyApp::Main::on_child_init);
when I replaced it with
Apache-push_handlers(PerlChildInitHandler,
sub { MyApp::Main::on_child_init(); });
it works as expected.
--
( Marcin Kasperski | You have the right to peace, fun, and
ctive )
( http://www.mk.w.pl |and enjoyable work.
)
(---
-)
( Nie gub zgosze bdw:
p://www.mk.w.pl/narzedzia/narzedzia_bugewid)
Re: $r-push_handlers('PerlAuthenHandler', 'Some::handler') doesn'twork
Rodney Broom wrote:
From: Per Einar Ellefsen [EMAIL PROTECTED]
dir_config is the Perl{Set,Add}Var configuration...
Yep, you're right. But I'm sort of grasping at straws at this point.
You can just add that and let your handler decide regardless of the value
of requires...
Yes, but there are side effects:
1. When the access handler finds a URI that doesn't need authentication turned on:
# httpd.conf
Location /
require jack handy
/Location
# Access handler
return OK; # Since we don't care about the current URI.
you should wipe the Authen and Authz handlers clean at this point, too.
$r-set_handlers(PerlAuthenHandler = [\OK]);
$r-set_handlers(PerlAuthzHandler = [\OK]);
see Recipe 13.5 in the Cookbook for more information, as well as the
'Satisfy Any' Apache configuration directive option - maybe some
combination of these will suit your needs.
HTH
--Geoff
Re: $r-push_handlers('PerlAuthenHandler', 'Some::handler') doesn'twork
From: Stas Bekman [EMAIL PROTECTED]
What happens if you do:
$r-set_handlers('PerlAuthenHandler', 'Some::handler');
Either of these:
$r-set_handlers('PerlAuthenHandler', 'Some::handler');
$r-set_handlers('PerlAuthenHandler', \Some::handler);
Yeild:
Can't set_handler with that value...
Which agrees with the Apache.pm docs.
This:
$r-set_handlers('PerlAuthenHandler', ['Some::handler']);
Yeilds:
Gives no error, Some::handler() doesn't get run.
could be that with push_handlers() you have some other handler that
takes over, before Some::handler has a chance to run.
With either push_handlers() or set_handlers(), get_handlers() says that
'Some::handler' is the only handler in 'PerlAuthenHandler'. So I know the action is
working according to mod_perl. As for something else taking over, there's nothing that
I can find on this sandbox installation. No Auth* in the config, no htaccess files,
and no other Perl*Handler directives in use.
Just on a lark, I tried installing a PerlAuthenHandler in the config, it worked just
fine.
---
Rodney Broom
President, R.Broom Consulting
http://www.rbroom.com/
Re: $r-push_handlers('PerlAuthenHandler', 'Some::handler') doesn'twork
Rodney Broom wrote:
Hi all,
I'm sure I'm just missing something, but I'm stumped.
I've got an access handler that does some tests and then conditionaly does this:
$r-push_handlers('PerlAuthenHandler', 'Some::handler');
return OK;
Some::handler() starts by printing the current callback to the error log, which
never happens if it's set to run in the 'PerlAuthenHandler'. If I change the
push_handlers() to use 'PerlFixupHandler', then Some::handler() gets called and I see
it in the error log.
What am I doing wrong? I know it has to be me.
you probably don't have a Require directive in your httpd.conf for
this particular Location. Apache will not run the Authen or Authz
phases unless there is a Require directive, no matter what you put
onto the mod_perl handler stack.
HTH
--Geoff
Re: $r-push_handlers('PerlAuthenHandler', 'Some::handler') doesn'twork
From: Geoffrey Young [EMAIL PROTECTED]
you probably don't have a Require directive in your httpd.conf for
this particular Location.
You're right, I don't. In fact, I can't. One of the things the access handler does is
to look up the URI in a database, which happens at run time. (The Location directive
would happen at server load time.) I need the access handler to decide wether or not
the requested URI needs authentication.
Apache will not run the Authen or Authz phases unless there is a
Require directive, no matter what you put onto the mod_perl handler stack.
I sort of thought this myself, so I tried $r-dir_config-add('require', 'valid-user')
in the access handler. No help.
---
Rodney Broom
President, R.Broom Consulting
http://www.rbroom.com/
Re: $r-push_handlers('PerlAuthenHandler', 'Some::handler') doesn'twork
At 21:05 01.09.2002, Rodney Broom wrote:
Apache will not run the Authen or Authz phases unless there is a
Require directive, no matter what you put onto the mod_perl handler stack.
I sort of thought this myself, so I tried $r-dir_config-add('require',
'valid-user') in the access handler. No help.
dir_config is the Perl{Set,Add}Var configuration, and has nothing to do
with Requires. Requires is set within httpd.conf like:
Require valid-user
You can just add that and let your handler decide regardless of the value
of requires (which is accessed through $r-requires btw, see the Eagle or
the cookbook).
--
Per Einar Ellefsen
[EMAIL PROTECTED]
Re: $r-push_handlers('PerlAuthenHandler', 'Some::handler') doesn'twork
From: Per Einar Ellefsen [EMAIL PROTECTED]
dir_config is the Perl{Set,Add}Var configuration...
Yep, you're right. But I'm sort of grasping at straws at this point.
You can just add that and let your handler decide regardless of the value
of requires...
Yes, but there are side effects:
1. When the access handler finds a URI that doesn't need authentication turned on:
# httpd.conf
Location /
require jack handy
/Location
# Access handler
return OK; # Since we don't care about the current URI.
# Error log
Some::handler(): Starting in [PerlAccessHandler].
Some::handler(): This uri [/one/onezie.fil] not under access control, returning OK.
configuration error: couldn't perform authentication. AuthType \
not set!: /one/onezie.fil
Although on areas where authentication is desired, this method works fine. We just
have to set r-auth_type and r-auth_name before returning from access control.
2. I don't want to have to add several lines to each VirtualHost that I use this
code in. Instead, we add a single handler at the URI Translation phase and let it
set up the rest of the handlers for the request. Actually, we already have a
system doing this and are very happy with the results. This Authen handler is just
intended to be an add-on to that.
...which is accessed through $r-requires btw...
Ah, you're right. Thank you. Unfortunately, this is read-only.
---
Rodney Broom
President, R.Broom Consulting
http://www.rbroom.com/
Re: $r-push_handlers('PerlAuthenHandler', 'Some::handler') doesn'twork
Rodney Broom wrote:
From: Stas Bekman [EMAIL PROTECTED]
What happens if you do:
$r-set_handlers('PerlAuthenHandler', 'Some::handler');
Either of these:
$r-set_handlers('PerlAuthenHandler', 'Some::handler');
$r-set_handlers('PerlAuthenHandler', \Some::handler);
Yeild:
Can't set_handler with that value...
Which agrees with the Apache.pm docs.
Ah, sorry. I'm living in the future. in mod_perl 2.0 you can pass
\@handlers or \handler for both set_handlers() and push_handlers().
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
$r-push_handlers('PerlAuthenHandler', 'Some::handler') doesn't work
Hi all,
I'm sure I'm just missing something, but I'm stumped.
I've got an access handler that does some tests and then conditionaly does this:
$r-push_handlers('PerlAuthenHandler', 'Some::handler');
return OK;
Some::handler() starts by printing the current callback to the error log, which never
happens if it's set to run in the 'PerlAuthenHandler'. If I change the push_handlers()
to use 'PerlFixupHandler', then Some::handler() gets called and I see it in the error
log.
What am I doing wrong? I know it has to be me.
---
Rodney Broom
President, R.Broom Consulting
http://www.rbroom.com/
Re: $r-push_handlers('PerlAuthenHandler', 'Some::handler') doesn't work
If you have an access handler return OK, then the access handling stops.
Because that handler handled it.
So as far as I know:
$r-push_handlers('PerlAuthenHandler', 'Some::handler');
return DECLINED;
should work...
-- Ryan
- Original Message -
From: Rodney Broom [EMAIL PROTECTED]
To: mod_perl list [EMAIL PROTECTED]
Sent: Saturday, August 31, 2002 6:59 PM
Subject: $r-push_handlers('PerlAuthenHandler', 'Some::handler') doesn't
work
Hi all,
I'm sure I'm just missing something, but I'm stumped.
I've got an access handler that does some tests and then conditionaly does
this:
$r-push_handlers('PerlAuthenHandler', 'Some::handler');
return OK;
Some::handler() starts by printing the current callback to the error log,
which never happens if it's set to run in the 'PerlAuthenHandler'. If I
change the push_handlers() to use 'PerlFixupHandler', then Some::handler()
gets called and I see it in the error log.
What am I doing wrong? I know it has to be me.
---
Rodney Broom
President, R.Broom Consulting
http://www.rbroom.com/
Re: $r-push_handlers('PerlAuthenHandler', 'Some::handler') doesn't work
From: Ryan Parr [EMAIL PROTECTED]
If you have an access handler return OK, then the access handling stops.
Because that handler handled it.
So as far as I know:
$r-push_handlers('PerlAuthenHandler', 'Some::handler');
return DECLINED;
should work...
Yeah, I tried that. I've also tried AUTH_REQUIRED, FORBIDDEN, and DONE. Since the
authentication phase is after the access phase, my guess has been that the return from
the access phase shouldn't effect the authentication phase. That is, of course, unless
the access phase returns something like SERVER_ERROR. Right?
---
Rodney Broom
President, R.Broom Consulting
http://www.rbroom.com/
Re: $r-push_handlers('PerlAuthenHandler', 'Some::handler') doesn'twork
Rodney Broom wrote:
From: Ryan Parr [EMAIL PROTECTED]
If you have an access handler return OK, then the access handling stops.
Because that handler handled it.
So as far as I know:
$r-push_handlers('PerlAuthenHandler', 'Some::handler');
return DECLINED;
should work...
Yeah, I tried that. I've also tried AUTH_REQUIRED, FORBIDDEN, and DONE. Since the
authentication phase is after the access phase, my guess has been that the return
from the access phase shouldn't effect the authentication phase. That is, of course,
unless the access phase returns something like SERVER_ERROR. Right?
What happens if you do:
$r-set_handlers('PerlAuthenHandler', 'Some::handler');
could be that with push_handlers() you have some other handler that
takes over, before Some::handler has a chance to run.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: method handlers and push_handlers / set_handlers
Stas Bekman wrote:
Tim Noll wrote:
Is there a proper way to call a method handler using either
push_handlers or
set_handlers? They both appear to call all handler refs just like normal
subs, with no class name passed in. It appears that enclosing the
handler in
an anonymous sub is a workaround, but I was wondering if there was a
better
solution.
# does not call handler as a method
$r-push_handlers( PerlHandler = \Apache::Test::handler );
# does call handler as a method
$r-push_handlers( PerlHandler = sub { Apache::Test-handler } );
See
http://perl.apache.org/guide/config.html#Perl_Method_Handlers, the eagle
and cookbook books.
PERL_METHOD_HANDLERS=1 + $$ prototype for Apache::Test::handler
My question was really about the proper way to call method handlers from
either push_handlers or set_handlers since the normal technique (first
example above) calls them as normal subs, i.e. the first parameter is not
the class name. The second example, however, seems to do the trick. I just
wanted to know whether there was a better technique and/or any pitfalls to
this technique. While searching around the web a bit more today, I came
across the example below from the mod_perl_method_handlers man page, which
seems to be similar, so I guess I'm on the right track. However, any
comments would still be appreciated.
snip
$r-push_handlers(PerlHandler =
sub {
my $r = shift;
$self-perl_handler_method($r);
}
);
/snip
-Tim
Re: method handlers and push_handlers / set_handlers
My question was really about the proper way to call method handlers from
either push_handlers or set_handlers since the normal technique (first
example above) calls them as normal subs, i.e. the first parameter is not
the class name. The second example, however, seems to do the trick. I just
wanted to know whether there was a better technique and/or any pitfalls to
this technique. While searching around the web a bit more today, I came
across the example below from the mod_perl_method_handlers man page, which
seems to be similar, so I guess I'm on the right track. However, any
comments would still be appreciated.
snip
$r-push_handlers(PerlHandler =
sub {
my $r = shift;
$self-perl_handler_method($r);
}
);
/snip
you need to push the handler by name
$r-push_handlers(PerlHandler = 'My::Handler');
at least until this patch makes it into mod_perl core...
http://marc.theaimsgroup.com/?l=apache-modperl-devm=101164617829467w=2
(though I forgot what the patch was for :)
at any rate, see the latter part of recipe 10.3 :)
--Geoff
method handlers and push_handlers / set_handlers
Is there a proper way to call a method handler using either push_handlers or
set_handlers? They both appear to call all handler refs just like normal
subs, with no class name passed in. It appears that enclosing the handler in
an anonymous sub is a workaround, but I was wondering if there was a better
solution.
# does not call handler as a method
$r-push_handlers( PerlHandler = \Apache::Test::handler );
# does call handler as a method
$r-push_handlers( PerlHandler = sub { Apache::Test-handler } );
-Tim
Re: method handlers and push_handlers / set_handlers
Tim Noll wrote:
Is there a proper way to call a method handler using either push_handlers or
set_handlers? They both appear to call all handler refs just like normal
subs, with no class name passed in. It appears that enclosing the handler in
an anonymous sub is a workaround, but I was wondering if there was a better
solution.
# does not call handler as a method
$r-push_handlers( PerlHandler = \Apache::Test::handler );
# does call handler as a method
$r-push_handlers( PerlHandler = sub { Apache::Test-handler } );
-Tim
See
http://perl.apache.org/guide/config.html#Perl_Method_Handlers, the eagle
and cookbook books.
PERL_METHOD_HANDLERS=1 + $$ prototype for Apache::Test::handler
--
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: method handlers and push_handlers / set_handlers
Tim Noll wrote:
I know this is a pretty generic question, but if nobody knows a quick
answer, I can get more specific in a later post. Under Apache 1.3.22 /
mod_perl 1.26, even while using $SIG{__WARN__} = \Carp::cluck, I keep
getting Use of uninitialized value. in the Apache error log, with
absolutely no line number or back trace or anything else. Does anybody
know
what might cause this? Thanks.
OK, in answer to my own question, after embedding debug statements all over
my code, I found the source of my problem: After finally moving this project
from Win2K to Debian, I neglected to update the driver string in
DBI-connect. How embarassing ... :-(
In any case, this still leaves the question: Why was there no line number or
back trace in the error log?
-Tim
Re: method handlers and push_handlers / set_handlers
Tim Noll wrote:
Tim Noll wrote:
I know this is a pretty generic question, but if nobody knows a quick
answer, I can get more specific in a later post. Under Apache 1.3.22 /
mod_perl 1.26, even while using $SIG{__WARN__} = \Carp::cluck, I keep
getting Use of uninitialized value. in the Apache error log, with
absolutely no line number or back trace or anything else. Does anybody
know
what might cause this? Thanks.
OK, in answer to my own question, after embedding debug statements all over
my code, I found the source of my problem: After finally moving this project
from Win2K to Debian, I neglected to update the driver string in
DBI-connect. How embarassing ... :-(
In any case, this still leaves the question: Why was there no line number or
back trace in the error log?
I guess because any code can disable your setting locally or globally by
overriding $SIG{__WARN__} using local() or without it after you've
defined it. Or simply turning warnings off locally or again globally
(horrors).
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: push_handlers
Stathy Touloumis [EMAIL PROTECTED] wrote:
For some reason the call to 'push_handlers' does not seem to register the
'handler' with mod_perl correctly when used in the code below. It seems
that only a few initial requests will successfully be processed by this
handler. It then just seems to be bypassed. It only works when the
'push_handler' code is commented out and a Perl*Handler directive is added
to the apache conf file. Does anyone know why this is so?
Here is a snippet of code which is read in at server startup through a
'require' directive.
Apache-push_handlers(
PerlPostReadRequestHandler= \handler
);
sub handler { warn Hello World\n; }
As far as I know, push_handlers only works the the current request --
that is, the handlers pushed with it are cleared at the end of the
request.
It would seem that doing this at startup sets up the handler which
then gets used by the children and cleared after the first request
they serve. This would give you the symptoms you're seeing (each
child called once, and then it disappears). Try running httpd -X to
see what happens. There's also probably something in the guide about
it.
--
James Smith [EMAIL PROTECTED], 979-862-3725
Texas AM CIS Operating Systems Group, Unix
RE: push_handlers
Makes sense, will look over the docs again.
Thanks,
Stathy Touloumis [EMAIL PROTECTED] wrote:
For some reason the call to 'push_handlers' does not seem to register the
'handler' with mod_perl correctly when used in the code below. It seems
that only a few initial requests will successfully be processed by this
handler. It then just seems to be bypassed. It only works when the
'push_handler' code is commented out and a Perl*Handler
directive is added
to the apache conf file. Does anyone know why this is so?
Here is a snippet of code which is read in at server startup through a
'require' directive.
Apache-push_handlers(
PerlPostReadRequestHandler= \handler
);
sub handler { warn Hello World\n; }
As far as I know, push_handlers only works the the current request --
that is, the handlers pushed with it are cleared at the end of the
request.
It would seem that doing this at startup sets up the handler which
then gets used by the children and cleared after the first request
they serve. This would give you the symptoms you're seeing (each
child called once, and then it disappears). Try running httpd -X to
see what happens. There's also probably something in the guide about
it.
push_handlers, set_handlers
Apache 1.3.22 mod_perl 1.26 I have noticed some strange behavior when attempting to stack handlers below the 'ChildInit' phase. This code executes fine when placed in a server initialization script: Apache-push_handlers( PerlChildInitHandler= \My::Child::handler ); When using the code below in a server initialization script without any apache config directives the handler does not get called. Apache-push_handlers( PerlHandler= \My::handler ); When applying the following apache conf directive the handler seems to only get called occasionally (initialization of child process?). Files *.html SetHandler perl-script /Files Although, when using the 'push_handlers' method at another part of the request phase the handler gets called occasionally. Apache-push_handlers( PerlFixupHandler= \My::Other::handler ); When using the method below the handlers do not get called at all. Apache-httpd_conf(EOF); Files *.html PerlHandler My::handler SetHandler perl-script /Files EOF Apache-httpd_conf(EOF); PerlFixupHandler My::Other::handler EOF Of course when setting the directives into the apache conf all seems to work well. PerlFixupHandler My::Other Files *.html PerlHandler My SetHandler perl-script /Files Any ideas as to why this strange behavior? When trying to use the 'set_handlers' method it blows up stating the request object is not created. I cannot see the reason why the request object should be needed to set/push handlers which are used to 'handle' the request phases. Thanks,
Apache-push_handlers
Hi,
I was wondering if anyone had experienced some funky behavior when 'pushing'
a content handler (PerlHandler). The initial request makes the appropriate
content handler call but upon subsequent requests the content handler
routine does not get called.
This is a snippet of code from a startup file that is loaded at system
startup:
my $environment = $ENV{'ENVIRONMENT'};
Apache-push_handlers( PerlHandler= sub {
return Package::Base::$environment-handler( shift );
} );
Thanks,
$r-set_handlers and $R-push_handlers
How can you specify a Location for these paramters, or can they be used only from within the current section? Issac Internet is a wonderful mechanism for making a fool ofyourself 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: $r-set_handlers and $R-push_handlers
How can you specify a Location for these paramters, or can they be used only from within the current section? $r is a request object, so modifications only affect the current request. If you want to affect all requests, you need to do it in the configuration stage. - Perrin
RE: $r-set_handlers and $R-push_handlers
set_handlers() and push_handlers() apply to the current request (except for the PerlRestartHandler and other handlers that are not request-oriented). it really doesn't make sense to have them apply only to a Location or otherwise - if you want them to apply only to a certain location use logic around $r-location, or use a Perl*Handler config within that Location. HTH --Geoff -Original Message-From: Issac Goldstand [mailto:[EMAIL PROTECTED]]Sent: Tuesday, November 20, 2001 11:22 AMTo: [EMAIL PROTECTED]Subject: $r-set_handlers and $R-push_handlers How can you specify a Location for these paramters, or can they be used only from within the current section? Issac Internet is a wonderful mechanism for making a fool ofyourself 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
push_handlers
Hi Is there any way that I could use $r-push_handlers(PerlHandler = myHandler); and send/include a query string with that? I need to push another handler with some specific form data. thanks -r
push_handlers
Hello again, The problem with push_handlers, I just realized, is that the PerlHandler argument assumes that its argument is a method, sub, within the same package/handler. However, I need some other handler to take over and finish the job. Chaining won't do since I don't know before hand which handler will step in. Any suggestions? thanks -r TOL: I am wondering if I should create a sub process?
RE: push_handlers
-Original Message-
From: Rasoul Hajikhani [mailto:[EMAIL PROTECTED]]
Sent: Friday, August 24, 2001 2:59 PM
To: [EMAIL PROTECTED]
Subject: push_handlers
Hello again,
The problem with push_handlers, I just realized, is that the
PerlHandler argument assumes that its argument is a method, sub,
within the same package/handler. However, I need some other handler to
take over and finish the job. Chaining won't do since I don't know
before hand which handler will step in.
Any suggestions?
$r-push_handlers(PerlHandler = 'My::Handler');
or
$r-push_handlers(PerlHandler = 'My::Handler::subroutine');
or
$r-push_handlers(PerlHandler = sub { });
or
$r-push_handlers(PerlHandler = \sub);
pick whichever form you need...
--Geoff
Re: push_handlers and PerlAuthenHandler troubles [second try]
On Tue, 26 Jun 2001, Bolt Thrower wrote:
My apologies if you've seen this twice.
For a particular Location, I'd like to selectively (i.e., based on
arbitrary criteria) determine whether a visitor needs authentication.
So I set up a Location section in httpd.conf as follows:
PerlAuthenHandler Intranet::CheckSiteAuthen
#PerlAuthenHandler Apache::AuthTicket-authenticate
package Intranet::CheckSiteAuthen;
...
sub handler {
my $r = shift;
$r-warn(starting CheckSiteAuthen);
$r-push_handlers(PerlAuthenHandler =
'Apache::AuthTicket-authenticate');
in the current sources, you cannot push a handler in the current
phase. you could use a PerlAccessHandler to push the PerlAuthenHandler
instead.
push_handlers and PerlAuthenHandler troubles
For a particular Location, I'd like to selectively (i.e., based on
arbitrary criteria) determine whether a visitor needs authentication.
So I set up a Location section in httpd.conf as follows:
Location /
AuthType Apache::AuthTicket
AuthName HomeIntranet
PerlAuthenHandler Intranet::CheckSiteAuthen
#PerlAuthenHandler Apache::AuthTicket-authenticate
PerlAuthzHandler Apache::AuthTicket-authorize
require valid-user
/Location
Intranet::CheckSiteAuthen looks like:
---[start]-
package Intranet::CheckSiteAuthen;
use strict;
use DBI;
use Apache::Constants qw(:common);
use Intranet::common;
use Data::Dumper;
sub handler {
my $r = shift;
$r-warn(starting CheckSiteAuthen);
$r-push_handlers(PerlAuthenHandler = 'Apache::AuthTicket-authenticate');
return DECLINED;
}
1;
---[end]-
But when I try to access a location under that configuration,
I see in my error log:
[Mon Jun 25 18:33:55 2001] [crit] [client 192.168.10.15] configuration error:
couldn't check user. No user file?: /u/IntranetLoginForm
(/u/IntranetLoginForm is the login CGI form that Apache::AuthTicket
uses).
All I'm trying to do at this point is set up a PerlAuthenHandler that
passes control to another one (Apache::AuthTicket-authenticate).
Of course, everything works with the configuration
Location /
AuthType Apache::AuthTicket
AuthName HomeIntranet
#PerlAuthenHandler Intranet::CheckSiteAuthen
PerlAuthenHandler Apache::AuthTicket-authenticate
PerlAuthzHandler Apache::AuthTicket-authorize
require valid-user
/Location
Any suggestions for me?
Thanks,
--
Steve Chadsey [EMAIL PROTECTED]
So drink to forget and drown all your sorrows
Bury your dreams and choose catharsis!
-- Sentenced, Nepenthe
RE: push_handlers and PerlAuthenHandler troubles
There are known bugs in push_handlers/set_handlers that I believe are
corrected in CVS and should be part of the 1.26 release. Perhaps these
bugs are the problem.
Regards,
Christian
-Original Message-
From: Bolt Thrower [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 25, 2001 10:50 PM
To: [EMAIL PROTECTED]
Subject: push_handlers and PerlAuthenHandler troubles
For a particular Location, I'd like to selectively (i.e., based on
arbitrary criteria) determine whether a visitor needs authentication.
So I set up a Location section in httpd.conf as follows:
Location /
AuthType Apache::AuthTicket
AuthName HomeIntranet
PerlAuthenHandler Intranet::CheckSiteAuthen
#PerlAuthenHandler Apache::AuthTicket-authenticate
PerlAuthzHandler Apache::AuthTicket-authorize
require valid-user
/Location
Intranet::CheckSiteAuthen looks like:
---[start]-
package Intranet::CheckSiteAuthen;
use strict;
use DBI;
use Apache::Constants qw(:common);
use Intranet::common;
use Data::Dumper;
sub handler {
my $r = shift;
$r-warn(starting CheckSiteAuthen);
$r-push_handlers(PerlAuthenHandler =
'Apache::AuthTicket-authenticate');
return DECLINED;
}
1;
---[end]-
But when I try to access a location under that configuration,
I see in my error log:
[Mon Jun 25 18:33:55 2001] [crit] [client 192.168.10.15]
configuration error: couldn't check user. No user file?:
/u/IntranetLoginForm
(/u/IntranetLoginForm is the login CGI form that Apache::AuthTicket
uses).
All I'm trying to do at this point is set up a PerlAuthenHandler that
passes control to another one (Apache::AuthTicket-authenticate).
Of course, everything works with the configuration
Location /
AuthType Apache::AuthTicket
AuthName HomeIntranet
#PerlAuthenHandler Intranet::CheckSiteAuthen
PerlAuthenHandler Apache::AuthTicket-authenticate
PerlAuthzHandler Apache::AuthTicket-authorize
require valid-user
/Location
Any suggestions for me?
Thanks,
--
Steve Chadsey [EMAIL PROTECTED]
So drink to forget and drown all your sorrows
Bury your dreams and choose catharsis!
-- Sentenced, Nepenthe
%ENV push_handlers
To all: I am putting together a site utilizing stacked handlers where the first of the modules uses the push_handlers call in order to dynamically choose a processing module. This 'pushed' handler then goes about processing the request filling up the %ENV with information for the next in the stack to use to produce the actual page. However, after a couple of hours of working with this set-up, I'm finding that nformation that is placed in the %ENV hash during the 'pushed' handler's processing stage are lost by the time the Templating module goes to look for them. Can anyone confirm that they've seen this, or can someone suggest a fix? I seem to be quite at a loss as to what to do... Thanks *so* much in advance!!! Terry Moran
RE: %ENV push_handlers
-Original Message- From: Terry Moran [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 27, 2001 3:39 PM To: [EMAIL PROTECTED] Subject: %ENV push_handlers To all: I am putting together a site utilizing stacked handlers where the first of the modules uses the push_handlers call in order to dynamically choose a processing module. This 'pushed' handler then goes about processing the request filling up the %ENV with information for the next in the stack to use to produce the actual page. However, after a couple of hours of working with this set-up, I'm finding that nformation that is placed in the %ENV hash during the 'pushed' handler's processing stage are lost by the time the Templating module goes to look for them. Can anyone confirm that they've seen this, or can someone suggest a fix? I seem to be quite at a loss as to what to do... since you are already using $r-push_handlers use $r-pnotes instead of %ENV. --Geoff
RE: %ENV push_handlers
well, something isn't quite right... you aren't by chance using method
handlers are you?
at this point, you may want to post (some) code and/or the relevant snippet
from your httpd.conf.
using push_handlers with pnotes has never been a problem for me
# from some handler somewhere
$r-pnotes(foo = 'bar');
$r-push_handlers(PerlCleanupHandler = sub {
warn shift-pnotes('foo');
});
works no problemo...
--Geoff
-Original Message-
From: Terry Moran
To: Geoffrey Young
Sent: 6/27/01 7:57 PM
Subject: Re: %ENV push_handlers
Geoff:
I really appreciate the help. I got a chance to play around some
more,
and it looks like this %ENV block is very specific to using
push_handlers,
and moreover that it's blocking pnotes notes methods of the mod_perl
API
as well. I was thinking maybe it was a version thing, but I'm at
mod_perl
1.25, so that looks like it checks out. What I'm left with is getting a
work-around, and I have one. I'm just going to need to push_handler my
templating mod in order to give it the proper %ENV, or pnotes values (if
I
can find the time to translate into it that is, unfortunately an
important
part of design ;) ).
Anyhow, I get the feeling that push_handlers is somehow acting as a
subrequest - which would explain all of this. Not that I've found that
documented. I really appreciate the background on this - thanks!!!
Terry
Geoffrey Young wrote:
sure...
pnotes was documented after the eagle book was published, but it's my
favorite method :)
I dunno why %ENV is misbehaving - IIRC there were some reports in
older
mod_perls, but I thought it was taken care of recently.
at any rate, %ENV is a resource drain - you're better off with
pnotes.
besides, they can hold references too, which makes life oh, so much
better...
my %hash;
$r-pnotes(FOO = \%hash);
my $href = $r-pnotes('FOO');
--Geoff
-Original Message-
From: Terry Moran
To: Geoffrey Young
Sent: 6/27/01 3:51 PM
Subject: Re: %ENV push_handlers
Geoff:
Thanks so much for the fast response! My version of the Eagle Book
doesn't even list that command, but it'll work like a charm. Just
leaves
me wondering why %ENV jumps around like that...
Thanks again!
Terry
Geoffrey Young wrote:
-Original Message-
From: Terry Moran [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 27, 2001 3:39 PM
To: [EMAIL PROTECTED]
Subject: %ENV push_handlers
To all:
I am putting together a site utilizing stacked handlers where
the
first of the modules uses the push_handlers call in order to
dynamically
choose a processing module. This 'pushed' handler then goes about
processing the request filling up the %ENV with information for
the
next in the stack to use to produce the actual page. However,
after
a
couple of hours of working with this set-up, I'm finding that
nformation
that is placed in the %ENV hash during the 'pushed' handler's
processing
stage are lost by the time the Templating module goes to look
for them.
Can anyone confirm that they've seen this, or can someone
suggest a fix?
I seem to be quite at a loss as to what to do...
since you are already using $r-push_handlers use $r-pnotes instead
of
%ENV.
--Geoff
push_handlers and PerlAuthenHandler troubles [second try]
My apologies if you've seen this twice.
For a particular Location, I'd like to selectively (i.e., based on
arbitrary criteria) determine whether a visitor needs authentication.
So I set up a Location section in httpd.conf as follows:
Location /
AuthType Apache::AuthTicket
AuthName HomeIntranet
PerlAuthenHandler Intranet::CheckSiteAuthen
#PerlAuthenHandler Apache::AuthTicket-authenticate
PerlAuthzHandler Apache::AuthTicket-authorize
require valid-user
/Location
Intranet::CheckSiteAuthen looks like:
---[start]-
package Intranet::CheckSiteAuthen;
use strict;
use DBI;
use Apache::Constants qw(:common);
use Intranet::common;
sub handler {
my $r = shift;
$r-warn(starting CheckSiteAuthen);
$r-push_handlers(PerlAuthenHandler =
'Apache::AuthTicket-authenticate');
return DECLINED;
}
1;
---[end]-
But when I try to access a location under that configuration,
I see in my error log:
[Mon Jun 25 18:33:55 2001] [crit] [client 192.168.10.15] configuration
error: couldn't
check user. No user file?: /u/IntranetLoginForm
(/u/IntranetLoginForm is the login CGI form that Apache::AuthTicket
uses).
All I'm trying to do at this point is set up a PerlAuthenHandler that
passes control to another one (Apache::AuthTicket-authenticate).
Of course, everything works with the configuration
Location /
AuthType Apache::AuthTicket
AuthName HomeIntranet
#PerlAuthenHandler Intranet::CheckSiteAuthen
PerlAuthenHandler Apache::AuthTicket-authenticate
PerlAuthzHandler Apache::AuthTicket-authorize
require valid-user
/Location
Any suggestions for me?
Thanks,
--
Steve Chadsey [EMAIL PROTECTED]
Now playing: Devil's Child
(Judas Priest - Screaming For Vengeance)
Re: push_handlers and PerlAuthenHandler troubles [second try]
- Original Message - From: Bolt Thrower [EMAIL PROTECTED] Location / AuthType Apache::AuthTicket AuthName HomeIntranet PerlAuthenHandler Intranet::CheckSiteAuthen #PerlAuthenHandler Apache::AuthTicket-authenticate PerlAuthzHandler Apache::AuthTicket-authorize require valid-user /Location But when I try to access a location under that configuration, I see in my error log: [Mon Jun 25 18:33:55 2001] [crit] [client 192.168.10.15] configuration error: couldn't check user. No user file?: /u/IntranetLoginForm mod_auth supplies the Auth* dirrectives. Since he sees 'require valid-user', he's looking for the rest of the Auth* directives. Specifically, AuthUserFile. I have a handler doing just what you are describing, and have the same problem. My solution was to mandate that my mudule was the only thing allowed to use Auth* configureation in the server config file and that everybody else had to use .htaccess. But I still see that message occasionally. My suggestion: if it work, then ignore the error message. :-) Of course, everything works with the configuration Location / AuthType Apache::AuthTicket ... /Location Any suggestions for me? Yep, Auth* happens at the Directory level. From the docs: AuthUserFile Context: directory, .htaccess So, if you have an other set of Auth* directives in the same scope, then that can cause conflicts --- Rodney Broom Programmer: Desert.Net
Re: push_handlers and PerlAuthenHandler troubles [second try]
Rodney Broom wrote: Location / AuthType Apache::AuthTicket AuthName HomeIntranet PerlAuthenHandler Intranet::CheckSiteAuthen #PerlAuthenHandler Apache::AuthTicket-authenticate PerlAuthzHandler Apache::AuthTicket-authorize require valid-user /Location mod_auth supplies the Auth* dirrectives. Since he sees 'require valid-user', he's looking for the rest of the Auth* directives. Specifically, AuthUserFile. Thanks for the reply Rodney. Anyway, I guess I just don't understand why I'm getting the user file error with the above config, but if I uncomment the PerlAuthenHandler Apache::AuthTicket-authenticate line, it works as it should (gives me a login page). All I want to do is have authentication start at my Intranet::CheckSiteAuthen module, then hop to the AuthTicket module if some condition is met. If I uncomment both PerlAuthenHandler Intranet::CheckSiteAuthen PerlAuthenHandler Apache::AuthTicket-authenticate lines, I get my login page, but authentication goes to Apache::AuthTicket-authenticate regardless of what happens in Intranet::CheckSiteAuthen. Thanks, -- Steve Chadsey [EMAIL PROTECTED]
RE: push_handlers question
-Original Message- From: Mike Cameron [mailto:[EMAIL PROTECTED]] Sent: Sunday, March 04, 2001 11:59 PM Cc: modperl Subject: push_handlers question I am trying to sub class Apache::AuthCookieURL and would like to use $r-push_handlers(PerlAuthenHandler = My::Class-authenticate); the push_handler is set in a handler called from httpd.conf on the PerlInitHandler phase but the authenticate routine does not seem to be getting the apache request object passed to it as I get a can't call dir_config on an udefined value error. my $r = Apache-request; HTH --Geoff I'm sure I am missing something simple but can someone point it out to me. Thanks
Re: push_handlers question
Thanks for the suggestion, but what i really want to know is why is the request object passed if I call the module directly from http.conf and not when I use the push handlers method? Are the two methods not functionally equivalent? Everything works fine when the handler is set in httpd.conf. Mike Geoffrey Young wrote: -Original Message- From: Mike Cameron [mailto:[EMAIL PROTECTED]] Sent: Sunday, March 04, 2001 11:59 PM Cc: modperl Subject: push_handlers question I am trying to sub class Apache::AuthCookieURL and would like to use $r-push_handlers(PerlAuthenHandler = My::Class-authenticate); the push_handler is set in a handler called from httpd.conf on the PerlInitHandler phase but the authenticate routine does not seem to be getting the apache request object passed to it as I get a can't call dir_config on an udefined value error. my $r = Apache-request; HTH --Geoff I'm sure I am missing something simple but can someone point it out to me. Thanks
RE: push_handlers question
-Original Message- From: Mike Cameron [mailto:[EMAIL PROTECTED]] Sent: Monday, March 05, 2001 10:18 AM Cc: '[EMAIL PROTECTED]' Subject: Re: push_handlers question Thanks for the suggestion, but what i really want to know is why is the request object passed if I call the module directly from http.conf and not when I use the push handlers method? Are the two methods not functionally equivalent? Everything works fine when the handler is set in httpd.conf. according to the mod_perl pocket reference (p20) method handlers do not get the request object passed to them - Andrew suggests using a closure for this. Apache-request should work fine as well. HTH --Geoff Mike Geoffrey Young wrote: -Original Message- From: Mike Cameron [mailto:[EMAIL PROTECTED]] Sent: Sunday, March 04, 2001 11:59 PM Cc: modperl Subject: push_handlers question I am trying to sub class Apache::AuthCookieURL and would like to use $r-push_handlers(PerlAuthenHandler = My::Class-authenticate); the push_handler is set in a handler called from httpd.conf on the PerlInitHandler phase but the authenticate routine does not seem to be getting the apache request object passed to it as I get a can't call dir_config on an udefined value error. my $r = Apache-request; HTH --Geoff I'm sure I am missing something simple but can someone point it out to me. Thanks
RE: push_handlers question
-Original Message- From: Geoffrey Young [mailto:[EMAIL PROTECTED]] Sent: Monday, March 05, 2001 9:58 AM To: 'Mike Cameron' Cc: '[EMAIL PROTECTED]' Subject: RE: push_handlers question -Original Message- From: Mike Cameron [mailto:[EMAIL PROTECTED]] Sent: Monday, March 05, 2001 10:18 AM Cc: '[EMAIL PROTECTED]' Subject: Re: push_handlers question Thanks for the suggestion, but what i really want to know is why is the request object passed if I call the module directly from http.conf and not when I use the push handlers method? Are the two methods not functionally equivalent? Everything works fine when the handler is set in httpd.conf. according to the mod_perl pocket reference (p20) method handlers do not get the request object passed to them I should have said method handlers that are set up via push_handlers() don't have the request object passed to them. for normal method handlers, $self = shift; $r = shift; works just fine. hopefully everyone understood that :) --Geoff - Andrew suggests using a closure for this. Apache-request should work fine as well. HTH --Geoff Mike Geoffrey Young wrote: -Original Message- From: Mike Cameron [mailto:[EMAIL PROTECTED]] Sent: Sunday, March 04, 2001 11:59 PM Cc: modperl Subject: push_handlers question I am trying to sub class Apache::AuthCookieURL and would like to use $r-push_handlers(PerlAuthenHandler = My::Class-authenticate); the push_handler is set in a handler called from httpd.conf on the PerlInitHandler phase but the authenticate routine does not seem to be getting the apache request object passed to it as I get a can't call dir_config on an udefined value error. my $r = Apache-request; HTH --Geoff I'm sure I am missing something simple but can someone point it out to me. Thanks
RE: push_handlers question
At 10:36 AM -0500 3/5/01, Geoffrey Young wrote:
Thanks for the suggestion, but what i really want to know is
why is the
request object passed if I call the module directly from
http.conf and not
when I use the push handlers method? Are the two methods not
functionally
equivalent? Everything works fine when the handler is set in
httpd.conf.
according to the mod_perl pocket reference (p20) method
handlers do not get
the request object passed to them
I should have said method handlers that are set up via push_handlers() don't
have the request object passed to them.
for normal method handlers,
$self = shift;
$r = shift;
Couldn't you fake it?
$r-push_handlers(
PerlHandler = sub{ unshift @_, Apache-request; goto real_handler; }
);
Robert Landrum
[snip]
--
"Will hack Perl for food."
RE: push_handlers question
-Original Message-
From: Robert Landrum [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 05, 2001 11:19 AM
To: Geoffrey Young; 'Mike Cameron'
Cc: [EMAIL PROTECTED]
Subject: RE: push_handlers question
At 10:36 AM -0500 3/5/01, Geoffrey Young wrote:
Thanks for the suggestion, but what i really want to know is
why is the
request object passed if I call the module directly from
http.conf and not
when I use the push handlers method? Are the two methods not
functionally
equivalent? Everything works fine when the handler is set in
httpd.conf.
according to the mod_perl pocket reference (p20) method
handlers do not get
the request object passed to them
I should have said method handlers that are set up via
push_handlers() don't
have the request object passed to them.
for normal method handlers,
$self = shift;
$r = shift;
Couldn't you fake it?
$r-push_handlers(
PerlHandler = sub{ unshift @_, Apache-request; goto
real_handler; }
);
there's always more than one way :)
--Geoff
Robert Landrum
[snip]
--
"Will hack Perl for food."
Re: push_handlers question
Thanks all. My real question was not so much HOW to fix but more WHY do
i need to fix. I did not realize that using push_handlers would not
send the Apache request to the method handler.
Geoffrey Young wrote:
-Original Message-
From: Robert Landrum [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 05, 2001 11:19 AM
To: Geoffrey Young; 'Mike Cameron'
Cc: [EMAIL PROTECTED]
Subject: RE: push_handlers question
At 10:36 AM -0500 3/5/01, Geoffrey Young wrote:
Thanks for the suggestion, but what i really want to know is
why is the
request object passed if I call the module directly from
http.conf and not
when I use the push handlers method? Are the two methods not
functionally
equivalent? Everything works fine when the handler is set in
httpd.conf.
according to the mod_perl pocket reference (p20) method
handlers do not get
the request object passed to them
I should have said method handlers that are set up via
push_handlers() don't
have the request object passed to them.
for normal method handlers,
$self = shift;
$r = shift;
Couldn't you fake it?
$r-push_handlers(
PerlHandler = sub{ unshift @_, Apache-request; goto
real_handler; }
);
there's always more than one way :)
--Geoff
Robert Landrum
[snip]
--
"Will hack Perl for food."
push_handlers question
I am trying to sub class Apache::AuthCookieURL and would like to use $r-push_handlers(PerlAuthenHandler = My::Class-authenticate); the push_handler is set in a handler called from httpd.conf on the PerlInitHandler phase but the authenticate routine does not seem to be getting the apache request object passed to it as I get a can't call dir_config on an udefined value error. I'm sure I am missing something simple but can someone point it out to me. Thanks
RE: push_handlers (was: PerlCleanupHandler vs register_cleanup)
a quick test showed the handlers to be FIFO, so I would expect you to get
moda
modb
modc
d
e
HTH
--Geoff
-Original Message-
From: Paul G. Weiss [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 24, 2000 2:38 PM
To: 'Stas Bekman'
Cc: modperl
Subject: push_handlers (was: PerlCleanupHandler vs register_cleanup)
While we're on the subject of handlers, if
I have
PerlLogHandlers moda modb modc
in my conf file
and I do
$r-push_handlers('PerlLogHandler', \d);
$r-push_handlers('PerlLogHandler', \e);
during the content phase
what is the order that the stacked log handlers run?
-P
-Original Message-
From: Stas Bekman [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 24, 2000 12:47 PM
To: Paul G. Weiss
Cc: modperl
Subject: Re: PerlCleanupHandler vs register_cleanup
On Thu, 24 Aug 2000, Paul G. Weiss wrote:
What is the difference between doing
$r-push_handlers('PerlCleanupHandler', \function);
and
$r-register_cleanup(\function);
The same:
http://www.modperl.com/book/chapters/ch9.html#Server_Core_Functions
The register_cleanup() method registers a subroutine that
will be called
after the logging stage of a request. This is much the same
as installing
a cleanup handler with the PerlCleanupHandler directive. See
Chapter 7 for
some practical examples of using register_cleanup().
_
Stas Bekman JAm_pH -- Just Another
mod_perl Hacker
http://stason.org/ mod_perl Guide
http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com
http://singlesheaven.com http://perlmonth.com perl.org apache.org
push_handlers (was: PerlCleanupHandler vs register_cleanup)
While we're on the subject of handlers, if
I have
PerlLogHandlers moda modb modc
in my conf file
and I do
$r-push_handlers('PerlLogHandler', \d);
$r-push_handlers('PerlLogHandler', \e);
during the content phase
what is the order that the stacked log handlers run?
-P
-Original Message-
From: Stas Bekman [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 24, 2000 12:47 PM
To: Paul G. Weiss
Cc: modperl
Subject: Re: PerlCleanupHandler vs register_cleanup
On Thu, 24 Aug 2000, Paul G. Weiss wrote:
What is the difference between doing
$r-push_handlers('PerlCleanupHandler', \function);
and
$r-register_cleanup(\function);
The same:
http://www.modperl.com/book/chapters/ch9.html#Server_Core_Functions
The register_cleanup() method registers a subroutine that
will be called
after the logging stage of a request. This is much the same
as installing
a cleanup handler with the PerlCleanupHandler directive. See
Chapter 7 for
some practical examples of using register_cleanup().
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com
http://singlesheaven.com http://perlmonth.com perl.org apache.org
More on the set_handlers() / push_handlers() bug...
Hello, again. Here's a quick summary of the problem: upon clearing the stack of handlers (with set_handlers(PerlAuthzHandlers = undef)) the server appears to not recognize when it has found a DirectoryIndex file and returns the contents of a directory instead of the index file. Since last writing on this topic, I upgraded to all of the newest versions (apache-1.3.12, perl-5.6, mod_perl-1.24) and configured mod_perl with PERL_TRACE=1. Looking at the error_log with the handler tracing on and httpd running in single-server mode, I discovered that the server does appear to cycle through the directory indexes, but doesn't realize when it has found one. I've attached two error logs for the request http://dw3.tivoli.com:81/home/passwd/group/: one with the cache enabled, one without. I've also attached a copy of the document returned by the server for the with-authz-cache request. The document is the auto-generated contents of the directory. As you can see, index.phtml does exist in the directory and is the first file searched for by the server. Does anyone have any ideas here? Can anyone reproduce the problem? I've also included the source for the AuthzCache and AuthzLDAP. If anyone could use at least the Cache code and see if you could reproduce the problem, I'd really appreciate it. I noticed that the error log with the cache enabled shows that subsequent internal requests (such as those you see when requesting a directory instead of a named file) don't reset the handler stack to what is in the configuration. See about line 65 of each log file for this difference. Regards, Christian - Christian Gilmore Infrastructure Tools Team Lead Web Multimedia Development Tivoli Systems, Inc. AuthzCache.pm AuthzLDAP.pm Title: Index of /home/passwd/group Index of /home/passwd/group NameLast modified Size Description Parent Directory18-May-2000 11:25 - display_group_info.p.. 07-Jun-2000 10:4511k group.phtml 08-Jun-2000 17:3818k index.phtml 05-Jun-2000 12:13 7k Apache/1.3.12 Server at dw3.tivoli.com Port 81 error_log_with_cache error_log_without_cache
RE: More on the set_handlers() / push_handlers() bug...
Forgive me for the obvious and probably stupid questions, (especially since I didn't see the earlier posts in which you probably answered them =o) but just for the record -- No problem. I appreciate your trying to help! Could you be misspelling "PerlAuthzHandler"? I note you said "PerlAuthzHandlers" with an 's' below Is that a feature I should kick myself for not being aware of? Or maybe just an email typo? Or a code error? (I do see it's a stack of handlerS, but) Heh. No, that was just a typo in my mail. I have it right in the handler code, which I had attached. Why undefine the handlers? Could you just use $r-set_handlers( PerlAuthzHandler = [ \OK ] ); or something? Could that be part of the problem? (Though I don't see how.I'm still pretty new to this.) Well, setting it to undef is what is recommended in the "Apache Modules" book (page 466), but I have tried setting it to \OK. Setting it to \OK turns out to do nothing at all. The server ignores your attempted change (even though it shows that it did change when you look at get_handlers) and continues as if you never even called set_handlers. Please, if you have the time and opportunity, give the AuthzCache a try. I'd really like to know that others can reproduce the problem. It can wrap around any perl Authz handler as follows: PerlAuthzHandler Tivoli::Apache::AuthzCache your authz handler here Tivoli::Apache::AuthzCache::manage_cache Regards, Christian - Christian Gilmore Infrastructure Tools Team Lead Web Multimedia Development Tivoli Systems, Inc.
push_handlers weirdness...
hi all...
I'm not sure if this is related to some of the get/set handler
strangeness that I have been seeing lately (as I try to do some weird
stacked handler acrobatics), or if it's the result of some closure thing
that I really shouldn't be doing...
package Test::Test;
use Apache::Constants qw( OK );
use strict;
sub handler
{
my $r = shift;
warn "outside..." . $r-current_callback . $r-uri;
$r-push_handlers(PerlCleanupHandler = sub { warn "inside..." .
$r-current_callback . $r-uri;
return OK;});
return OK;
}
1;
anyway, for / = /index.html translation using mod_dir, this PerlInitHandler
produces:
outside...PerlInitHandler/ at /usr/lib/perl5/site_perl/5.005/Test/Test.pm
line 9.
outside...PerlInitHandler/index.html at
/usr/lib/perl5/site_perl/5.005/Test/Test.pm line 9.
inside...PerlCleanupHandler/ at /usr/lib/perl5/site_perl/5.005/Test/Test.pm
line 10.
inside...PerlFixupHandler/index.html at
/usr/lib/perl5/site_perl/5.005/Test/Test.pm line 10.
changing shift() to Apache-request() yields:
outside...PerlInitHandler/ at /usr/lib/perl5/site_perl/5.005/Test/Test.pm
line 10.
outside...PerlHandler/ at /usr/lib/perl5/site_perl/5.005/Test/Test.pm line
10.
inside...PerlCleanupHandler/ at /usr/lib/perl5/site_perl/5.005/Test/Test.pm
line 11.
inside...PerlCleanupHandler/ at /usr/lib/perl5/site_perl/5.005/Test/Test.pm
line 11.
which still isn't quite right, but sorta like what I might expect when
reading through mod_dir code and the ap_internal_redirect docs...
I tried playing around with setting $r in the anon subroutine too, but I
still can't get push_handlers to push code to the cleanup phase for the
internal redirect...
I guess the question I have is what's being shift()ed that for that second
pass and if the problem is just my code, mod_perl, mod_dir, or
not-a-problem/expected behavior...
fun, eh?
--Geoff
Re: push_handlers weirdness...
On: Wed, 31 May 2000 17:04:05 EDT Geoffrey Young wrote:
hi all...
I'm not sure if this is related to some of the get/set handler
strangeness that I have been seeing lately (as I try to do some weird
stacked handler acrobatics), or if it's the result of some closure thing
that I really shouldn't be doing...
package Test::Test;
use Apache::Constants qw( OK );
use strict;
sub handler
{
my $r = shift;
warn "outside..." . $r-current_callback . $r-uri;
$r-push_handlers(PerlCleanupHandler = sub { warn "inside..." .
$r-current_callback . $r-uri;
return OK;});
return OK;
}
1;
anyway, for / = /index.html translation using mod_dir, this PerlInitHandler
produces:
outside...PerlInitHandler/ at /usr/lib/perl5/site_perl/5.005/Test/Test.pm
line 9.
outside...PerlInitHandler/index.html at
/usr/lib/perl5/site_perl/5.005/Test/Test.pm line 9.
inside...PerlCleanupHandler/ at /usr/lib/perl5/site_perl/5.005/Test/Test.pm
line 10.
inside...PerlFixupHandler/index.html at
/usr/lib/perl5/site_perl/5.005/Test/Test.pm line 10.
Hi Geoff,
Isn't this what's expected? The first time through (for "/") you push code
onto the CleanupHandler stack.
Then there's a subrequest (by mod_dir, although I'm just guessing here) to
check for "/index.html", which causes another code ref to be pushed onto
the CleanupHandler stack.
At the completion of the subrequest, the original request is completed,
having two code refs to evaluate once it reaches the Cleanup "phase", one
for the original "/" and one for the "/index.html".
Or am I totally missing your point :)
--kip
