[pmwiki-users] pmform captchas bypassed on thinkhost.com

[Patrick R. Michaud]

On Mon, Jul 14, 2008 at 04:05:32PM +0100, Hans wrote:
> Monday, July 14, 2008, 3:28:29 PM, Patrick R. Michaud wrote:
> 
> > I see three possible solutions to this:
> 
> > 1.  Make Captcha part of the core, with Site.EditForm preconfigured to
> >     display a captcha whenever $EnablePostRequiresCaptcha is set.
> 
> > 2.  Leave Captcha as a recipe, but modify the distributed Site.EditForm
> >     to display a captcha whenever $EnablePostRequiresCaptcha is set.
> 
> > 3.  Provide a Site.EditForm with the Captcha recipe, and instructions
> >     to tell an admin how to configure it into the system (this actually
> >     may be the status quo).
> 
> I don't like any of these, as I don't see the point in a Captcha on
> the edit form. Most wikis I guess trust their editors enough not to
> require them to input captcha values. Often the edit access is
> restricted by password.

Note that as I worded #1 and #2 above, even though Site.EditForm
is preconfigured to display a captcha, the captcha itself won't
be displayed unless $EnablePostRequiresCaptcha is set.  So, someone
installing a new site won't see captchas in edit forms at all 
until they set $EnablePostRequiresCaptcha .

> I recommend to advise admins who want to use the Captcha recipe
> to add something like this to config.php, for wikis with edit
> access restrictions:
> 
> $EnablePostCaptchaRequired = 1;
> if (CondAuth($pagename,'edit'))
>         $EnablePostCaptchaRequired = 0;
> include_once('cookbook/captcha.php');

Something like this can be done as well, yes.  Easier might
be to modify the captcha recipe to do something like this
directly.  Or, perhaps we could even do it with something like

    $DefaultPasswords['edit'] = '@captcha';

to mean that an authenticated captcha is required to edit
the page.

Pm