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.
teste
teste
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^)
[Http-webtest-general] [ANNOUNCE] HTTP-WebTest-Plugin-TagAttTest-1.00
The uploaded file
HTTP-WebTest-Plugin-TagAttTest-1.00.tar.gzhas entered CPAN
as file:
$CPAN/authors/id/E/EF/EFANCHE/HTTP-WebTest-Plugin-TagAttTest-1.00.tar.gz
size: 5312 bytes md5: 940013aada679fdc09757f119d70686e
NAME HTTP::WebTest ::Plugin::TagAttTest - WebTest
plugin providing a higher level tag and attribute search interface.
DESCRIPTION see also http://search.cpan.org/search?query=HTTP%3A%3AWebTestmode=all
This module is a plugin extending the functionality of the WebTest module to
allow tests of the form:
my $webpage='http://www.ethercube.net';my @result;
@result = (@result, {test_name = "title
junk",url
=
$webpage,tag_forbid
= [{ tag="title", tag_text="junk"}]});@result = (@result,
{test_name = "title test
page",url
=
$webpage,tag_require
= [{tag= "title", text="test page"}]});@result = (@result,
{test_name = "type att with xml in
value",url
=
$webpage,tag_forbid
= [{attr="type", attr_text="xml" }]});@result = (@result,
{test_name = "type class with body in
value",url
=
$webpage,tag_require
= [{attr="class", attr_text="body" }]});@result =
(@result, {test_name = "class
att",url
=
$webpage,tag_require
= [{attr="class"}]});@result = (@result, {test_name
= "script
tag",url
=$webpage,tag_forbid
= [{tag= "script"}]});@result = (@result, {test_name =
"script tag with attribute
language=_javascript_",url
=
$webpage,tag_forbid
=
[{tag="script",attr="language",attr_text="_javascript_"}]});my
[EMAIL PROTECTED];
my $params = {
plugins =
["::FileRequest","HTTP::WebTest::Plugin::TagAttTest"]
};my $webtest= HTTP::WebTest-new;#4check_webtest(webtest
=$webtest, tests= $tests,opts=$params,
check_file='t/test.out/1.out');#$webtest-run_tests(
$tests,$params);
Ed FancherEthercube Solutionshttp://www.ethercube.netPHP, Perl,
MySQL, _javascript_ solutions.
