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
"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 A&M CIS Operating Systems Group, Unix
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
> -Original Message- > From: Adam Sussman [mailto:[EMAIL PROTECTED]] > Sent: Friday, August 24, 2001 1:29 PM > To: 'Rasoul Hajikhani' > Cc: [EMAIL PROTECTED] > Subject: RE: push_handlers > > > > You should always have access to $r->args so long as you > haven't altered it > in another handler. If you need to carry post data, you could use > $r->pnotes > or else you could cache an Apache::Request object for the > duration of the > request. > no need to do this yourself - use Apache::Request->instance($r) or Apache::RequestNotes --Geoff
Re: push_handlers
___cliff rayman___ wrote: > > looks like you got your module working? > > checkout $r->pnotes(); > > Rasoul Hajikhani wrote: > > > 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 > > -- > ___cliff [EMAIL PROTECTED]http://www.genwax.com/ Actually not yet. But I am taking another route. Thanks for the reply... -r
RE: push_handlers
You should always have access to $r->args so long as you haven't altered it in another handler. If you need to carry post data, you could use $r->pnotes or else you could cache an Apache::Request object for the duration of the request. -adam -Original Message- From: Rasoul Hajikhani [mailto:[EMAIL PROTECTED]] Sent: Friday, August 24, 2001 10:11 AM To: [EMAIL PROTECTED] Subject: 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
Re: push_handlers
looks like you got your module working? checkout $r->pnotes(); Rasoul Hajikhani wrote: > 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 -- ___cliff [EMAIL PROTECTED]http://www.genwax.com/
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:
>
>
> AuthType Apache::AuthTicket
> AuthName HomeIntranet
> PerlAuthenHandler Intranet::CheckSiteAuthen
> #PerlAuthenHandler Apache::AuthTicket->authenticate
> PerlAuthzHandler Apache::AuthTicket->authorize
> require valid-user
>
>
> 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
>
>
> AuthType Apache::AuthTicket
> AuthName HomeIntranet
> #PerlAuthenHandler Intranet::CheckSiteAuthen
> PerlAuthenHandler Apache::AuthTicket->authenticate
> PerlAuthzHandler Apache::AuthTicket->authorize
> require valid-user
>
>
> 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]
Rodney Broom wrote: > > > > > AuthType Apache::AuthTicket > > AuthName HomeIntranet > > PerlAuthenHandler Intranet::CheckSiteAuthen > > #PerlAuthenHandler Apache::AuthTicket->authenticate > > PerlAuthzHandler Apache::AuthTicket->authorize > > require valid-user > > > > > 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 and PerlAuthenHandler troubles [second try]
- Original Message - From: Bolt Thrower <[EMAIL PROTECTED]> > > AuthType Apache::AuthTicket > AuthName HomeIntranet > PerlAuthenHandler Intranet::CheckSiteAuthen > #PerlAuthenHandler Apache::AuthTicket->authenticate > PerlAuthzHandler Apache::AuthTicket->authorize > require valid-user > > 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 > > AuthType Apache::AuthTicket > ... > > 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 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 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
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: 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
> -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
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: 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 (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
