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.
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.
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
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."
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
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
