On 24/08/2010 13:56, Ray Morris wrote:
This sounds to me like an access_checker, which should be
called from the access_checker hook. Filters, as I understand
it, are for transforming the content - compressing it, for example.
Entirely replacing the content with an unrelated document sounds
like an abuse of filters. I wonder if this might be a case of
"if all you have is a hammer ..."
On a different note, if this CAPTCHA (until recently called a
Turing image) is just to reduce spam, great. If it's part of a
system designed to actually be secure, be very very careful.
I'm very much a jack of all trades. Mostly, I learn by trial and
error. There are only two areas I don't learn by trial and
error, because error is not acceptable. Explosives and system
security.
--
Ray Morris
supp...@bettercgi.com
Strongbox - The next generation in site security:
http://www.bettercgi.com/strongbox/
Throttlebox - Intelligent Bandwidth Control
http://www.bettercgi.com/throttlebox/
Strongbox / Throttlebox affiliate program:
http://www.bettercgi.com/affiliates/user/register.php
On 08/24/2010 07:29:53 AM, Martin Townsend wrote:
On 24/08/2010 11:19, Ben Noordhuis wrote:
On Tue, Aug 24, 2010 at 11:50, Martin Townsend
<martin.towns...@power-oasis.com> wrote:
Do you mean setting a request note from the input filter that an
output
filter picks up which can then output the captcha.shtml?
Yes, if your module consists of filters only. If it also includes a
content generator, I'd probably do it from there. But you know your
code best so pick the most appropriate solution.
I don't have a content generator. Can I call
ap_internal_redirect_handler to perform the redirect from my output
filter or do I have to destroy the original bucket brigade and load
the contents of captcha.shtml into a new one (in which case how do I
ensure that the SSI output filter is called as captcha.shtml contains
SSI). If I can call ap_internal_redirect_handler how do I stop the
original request from generating a response after
ap_internal_redirect_handler returns?
Best Regards,
Martin.
Hi Ray,
The same problem exists with the access_checker hook, reading the post
data to check the captcha code. The best way to do this is within the
input filter. I could use ap_get_client_block but this seems a bit of a
hack to me, plus is consumes the data.
The reason for the captcha is to stop customers from using our web
server on our embedded platform as a data logger. I haven't got as far
as security but I'm hoping it will be handled by AAA.
I now have something working, it seems a bit of a cludge but it works.
Using shared memory I store session information which contains the
captcha code, the state of the session etc. During the input filter
phase any captcha POST data is validated and update the session info.
Then during the output phase I decide on whether to display the captcha
page, e.g.
if(ap_is_initial_req(filter_in_p->r)
&& apr_strnatcasecmp(filter_in_p->r->content_type, "text/html") == 0
&& captcha_display_needed(filter_in_p->r)
&& strstr(filter_in_p->r->filename, "captcha.shtml") == NULL
) {
apr_brigade_destroy(bb_in_p);
ap_internal_redirect_handler("/captcha.shtml", filter_in_p->r);
filter_in_p->r->status = HTTP_MOVED_TEMPORARILY;
return DONE;
}
captcha_display_needed will retrieve the session and check it's validated.
Best Regards,
Martin.
