[pmwiki-users] Pondering adding comment ability to wiki pages, and thoughts on spam prevention

[John Rankin]

> On Mon, Mar 19, 2012 at 2:35 PM, Peter Bowers <pbowers at pobox.com> wrote:
>> On Mon, Mar 19, 2012 at 10:13 AM, tamouse mailing lists
>> <tamouse.lists at gmail.com> wrote:
>>> On Tue, Mar 13, 2012 at 1:11 PM, Simon <nzskiwi at gmail.com> wrote:
>>>> Have a look at the way we stop spam here.
>>>
>>> Just giving a password in clear text so a live user can type it in --
>>> I had heard of that, but wasn't sure how well it worked. Can you
>>> unpack a little more of what you're doing here? I don't know where to
>>> modify the login form, and does this method work with AuthUser as
>>> well, so you can have both anonymous and authorized people editing
>>> things?
>>
>> http://www.pmwiki.org/wiki/Cookbook/OpenPass
>>
>> -Peter
>
> Oh, thanks, Peter. That's a pretty good jumping off point for me,
> especially option #2. That looks like it might be good for some parts
> of what I want to do.
>
> Simon, is this how your site implements the guest editing password?
>
> I'd still like to be able to allow humans to freely comment on
> *-Comment pages if possible, even without a captcha or having to log
> in using a well-known password. I'd like to pull out as much
> interference as possible so they don't just walk away. It greatly
> annoys me to have to go through an extra step to leave a quick
> drive-by comment someplace, and I'd like to avoid annoying visitors.

Have you investigated the option of a "honey trap"? That is, a field
within a <div> with a class for display:none, so a human doesn't see it.
The theory being that if the field is filled in, it must be a spambot, so
reject the comment. It would be interesting to know how well this works in
practice, because it is simple to implement (a field, a css class and an
if statement) and adds no burden to human commenters. No password or
captcha is required.

JR
-- 
John Rankin