RE: Tracing double accesshandler invocation
Hi Ric,
This has been a nightmare trying to debug, but I think I've found where
the cause is in my module.
In my Access handler I have some code designed to skip Access handling for
images (let the html pages take care of that). The code calls
$r-lookup_uri to check on the content type of the file being requested,
which, according to the mod_perl cookbook, forces the subrequest back
through the Access and Auth stages (recipe 3.15, pp. 114-116).
if ($r-lookup_uri($r-uri)-content_type =~ /image/) {
return Apache::DECLINED;
}
Do you have this, or something similar, in your code?
My debugging was greatly complicated by the fact the the Apache::Test
framework apparently requests / from the server as a ping before
starting any tests. So I was consistently getting five calls to the Access
handler for the four tests in t/hooks.access.t when reconfigured to use
TesHooks::access for Location / -- watch out for this, all.
- nick
--
Nick Tonkin {|8^)
Re: Tracing double accesshandler invocation
Nick Tonkin wrote:
Hi Ric,
This has been a nightmare trying to debug, but I think I've found where
the cause is in my module.
In my Access handler I have some code designed to skip Access handling for
images (let the html pages take care of that). The code calls
$r-lookup_uri to check on the content type of the file being requested,
which, according to the mod_perl cookbook, forces the subrequest back
through the Access and Auth stages (recipe 3.15, pp. 114-116).
if ($r-lookup_uri($r-uri)-content_type =~ /image/) {
return Apache::DECLINED;
}
that seems like a lot of processing in this particular case - I'd be more
tempted to use that for _other_ URIs rather than the current URI. isn't it
just easier to not configure your access handler for image directories?
though I suppose that you have a reason for doing it like you are :)
as an aside, if you're using mod_perl 1.0 and feeling adventuresome, you
can actually call mod_mime's MIME checker routine on demand, then check
$r-content_type on the current request. see recipe 8.9 in the cookbook, or
the code
http://www.modperlcookbook.org/code/ch08/Cookbook/MIMEMagic.pm
:)
oh, and I suppose that you could always use the
File::MMagic-new-checktype_filename($r-filename)
bit instead of the full lookup as well and still come out ahead.
--Geoff
Re: Tracing double accesshandler invocation
Nick,
if ($r-lookup_uri($r-uri)-content_type =~ /image/) {
return Apache::DECLINED;
}
Do you have this, or something similar, in your code?
I greped my entire directory tree for any of the subrequest mechanisms
and the only place I am using them are in some handlers from a completely
different Location.
My access handler is essentially the same as the one from the eagle book but
with various modifications to suit my applications security requirements and
to use my own db/template objects. It doesn't use any subrequest mechanisms.
The only thing which it does which is affected by anything outside of its
immediate environment is call, $r-prev. This shouldn't call the
accesshandler though... should it?
Ric.
Re: Tracing double accesshandler invocation
The only thing which it does which is affected by anything outside of its immediate environment is call, $r-prev. This shouldn't call the accesshandler though... should it? Erm, doh, not sure why I said this. This only happens when a 403 happens and the user is sent to the /login location. So my actual AccessHandler doesn't do anything which even resembles a subrequest. Ric.
Re: Tracing double accesshandler invocation
On Fri, 14 Mar 2003, Richard Clarke wrote:
The only thing which it does which is affected by anything outside of its
immediate environment is call, $r-prev. This shouldn't call the
accesshandler though... should it?
Erm, doh, not sure why I said this. This only happens when a 403 happens and
the user is sent to the /login location. So my actual AccessHandler doesn't
do anything which even resembles a subrequest.
can you post the handler?
- nick
--
Nick Tonkin {|8^)
Re: Tracing double accesshandler invocation
package AC::Centry::Access;
$AC::Centry::Access::VERSION = qw$Revision: 1.2 $[1];
use strict;
use Apache::Constants qw(:common);
use AC::Centry::Tool();
# handler()
# Process requests to protected URI's
sub handler {
my $r = shift;
my $uri = $r-the_request;
return OK unless $r-is_initial_req; # stops dbl execution
$r-log-warn(Centry::Access triggered for $uri);
my $group = int $r-dir_config('AccessGroup');
# Create Config, Centry::Tool and verify_ticket
my $centry_tool = AC::Centry::Tool-new($r);
$r-log_reason(Bad Centry::Tool,$r-filename) unless $centry_tool;
my ($result, $msg) = $centry_tool-verify_ticket($r,$group);
# Return FORBIDDEN or short circuit with group
unless ($result) {
$r-log_reason($msg, $r-filename);
$centry_tool-expire_cookie($r); # Expire cookie from browser
unless ($group==0) {
my $cookie = $centry_tool-make_return_address($r);
$r-err_header_out('Set-Cookie' = $cookie-as_string);
return FORBIDDEN;
}
}
# Ticket is verified, Refresh ticket
$r-log-warn(Reissuing ticket with ,join ':',@$msg);
my $ticket = $centry_tool-make_ticket($r,@$msg);
$r-err_header_out('Set-Cookie', $ticket-as_string);
return OK;
}
Re: Tracing double accesshandler invocation
On Fri, 14 Mar 2003, Richard Clarke wrote:
package AC::Centry::Access;
$AC::Centry::Access::VERSION = qw$Revision: 1.2 $[1];
use strict;
use Apache::Constants qw(:common);
use AC::Centry::Tool();
# handler()
# Process requests to protected URI's
sub handler {
my $r = shift;
my $uri = $r-the_request;
return OK unless $r-is_initial_req; # stops dbl execution
Stops dbl execution _after_ this point, of course. If you request a
directory, the server will return an internal redirect to $dir/index.html
(or whatever) -- that would make your handler run twice up to this point.
Try taking that code out and running the test with a URL that points to a
file.
Also, I think it's better to return DECLINED from your Access handler if
you're not returning FORBIDDEN, rather than OK, since there may be other
handlers that need to work on the request. And if not now, maybe in the
future.
- nick
--
Nick Tonkin {|8^)
Re: Tracing double accesshandler invocation
sub handler {
my $r = shift;
my $uri = $r-the_request;
return OK unless $r-is_initial_req; # stops dbl execution
Stops dbl execution _after_ this point, of course. If you request a
directory, the server will return an internal redirect to $dir/index.html
(or whatever) -- that would make your handler run twice up to this point.
I'm not sure what you mean.
The reason that I put that code there is because if it's not there then the
accesshandler is always run twice.
There seems to be a subrequest triggering the accesshandler, yet I'm not
explicitly performing any subrequests.
Ideally I would like to find someway to trace the who/what/where/why of
handler execution. Running with PERL_TRACE left me none the wiser so I was
hoping a user might know a better way?
Richard.
Re: Tracing double accesshandler invocation
On Fri, 14 Mar 2003, Richard Clarke wrote:
sub handler {
my $r = shift;
my $uri = $r-the_request;
return OK unless $r-is_initial_req; # stops dbl execution
Stops dbl execution _after_ this point, of course. If you request a
directory, the server will return an internal redirect to $dir/index.html
(or whatever) -- that would make your handler run twice up to this point.
I'm not sure what you mean.
The reason that I put that code there is because if it's not there then the
accesshandler is always run twice.
There seems to be a subrequest triggering the accesshandler, yet I'm not
explicitly performing any subrequests.
What I meant was that if you request http://yourdomain.com/some/path then
the server will return a redirect to
http://yourdomain.com/some/path/index.html, which will cause tha access
handler to be invoked a second time.
Ideally I would like to find someway to trace the who/what/where/why of
handler execution. Running with PERL_TRACE left me none the wiser so I was
hoping a user might know a better way?
Richard.
- nick
--
Nick Tonkin {|8^)
Re: Tracing double accesshandler invocation
On Thu, 6 Mar 2003, Stas Bekman wrote:
Nick Tonkin wrote:
On Wed, 5 Mar 2003, Richard Clarke wrote:
Hi,
I'm trying to figure out why my accesshandler is getting triggered twice
for each request that I make. I'm 100% sure that I'm doing no explicit
lookups/redirects anywhere in my code. The particular uri I am fetching
should only invocate an accesshandler followed by a contenthandler.
After watching the request with MOD_PERL_TRACE=h and MOD_PERL_TRACE=all I
think I'm still non the wiser.
Testing for $r-is_initial_req solves the problem but I'm more interested
in finding out exactly why it's being called twice.
Any tips for tracing this easier?
Nope, but FWIW I see the same behavior. I'm using mp2, but IIRC the same
thing used to happen on mp1 too.
I too would very much like to figure this out. I sort of suspect it is in
how the httpd.conf auth* directives are specified, but I've never had the
time to really muck around with them.
If you provide me a simple mp2 setup where this happens, I can debug it.
However if I run with mp2:
t/TEST -v hooks/access
and log from TestHooks/access.pm every time an access handler is called, I can
see it called only once per request. So may be play with this test's config
until you break it. if you succeed to break it, that would be the easiest for
me to reproduce your problem.
This is on my list of things to do.
- nick
--
Nick Tonkin {|8^)
Re: Tracing double accesshandler invocation
On Wed, 5 Mar 2003, Richard Clarke wrote:
Hi,
I'm trying to figure out why my accesshandler is getting triggered twice
for each request that I make. I'm 100% sure that I'm doing no explicit
lookups/redirects anywhere in my code. The particular uri I am fetching
should only invocate an accesshandler followed by a contenthandler.
After watching the request with MOD_PERL_TRACE=h and MOD_PERL_TRACE=all I
think I'm still non the wiser.
Testing for $r-is_initial_req solves the problem but I'm more interested
in finding out exactly why it's being called twice.
Any tips for tracing this easier?
Nope, but FWIW I see the same behavior. I'm using mp2, but IIRC the same
thing used to happen on mp1 too.
I too would very much like to figure this out. I sort of suspect it is in
how the httpd.conf auth* directives are specified, but I've never had the
time to really muck around with them.
- nick
--
Nick Tonkin {|8^)
Re: Tracing double accesshandler invocation
On Wed, 5 Mar 2003, Richard Clarke wrote:
Hi,
I'm trying to figure out why my accesshandler is getting triggered twice
for each request that I make. I'm 100% sure that I'm doing no explicit
lookups/redirects anywhere in my code. The particular uri I am fetching
should only invocate an accesshandler followed by a contenthandler.
After watching the request with MOD_PERL_TRACE=h and MOD_PERL_TRACE=all I
think I'm still non the wiser.
Testing for $r-is_initial_req solves the problem but I'm more interested
in finding out exactly why it's being called twice.
Any tips for tracing this easier?
Ric.
Nope, but FWIW I see the same behavior. I'm using mp2, but IIRC the same
thing used to happen on mp1 too.
I too would very much like to figure this out. I sort of suspect it is in
how the httpd.conf auth* directives are specified, but I've never had the
time to really muck around with them.
- nick
--
Nick Tonkin {|8^)
Re: Tracing double accesshandler invocation
Nick Tonkin wrote: On Wed, 5 Mar 2003, Richard Clarke wrote: Hi, I'm trying to figure out why my accesshandler is getting triggered twice for each request that I make. I'm 100% sure that I'm doing no explicit lookups/redirects anywhere in my code. The particular uri I am fetching should only invocate an accesshandler followed by a contenthandler. After watching the request with MOD_PERL_TRACE=h and MOD_PERL_TRACE=all I think I'm still non the wiser. Testing for $r-is_initial_req solves the problem but I'm more interested in finding out exactly why it's being called twice. Any tips for tracing this easier? Nope, but FWIW I see the same behavior. I'm using mp2, but IIRC the same thing used to happen on mp1 too. I too would very much like to figure this out. I sort of suspect it is in how the httpd.conf auth* directives are specified, but I've never had the time to really muck around with them. If you provide me a simple mp2 setup where this happens, I can debug it. However if I run with mp2: t/TEST -v hooks/access and log from TestHooks/access.pm every time an access handler is called, I can see it called only once per request. So may be play with this test's config until you break it. if you succeed to break it, that would be the easiest for me to reproduce your problem. __ 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
