[pmwiki-users] Pondering adding comment ability to wiki pages, and thoughts on spam prevention
tamouse mailing lists
I've long been contemplating adding commenting ability to my wiki
pages (or some of them) and I've been debating different ways of doing
this. I've read through the various cook book recipes and weighed
different methods and options.
I like the idea of -Talk pages as implemented in pmwiki.org to hold
discussions. It seems like a pretty straight-forward way of providing
that sort of mechanism if you want to hold discussions about the
contents of the base page. However, it really does seem quite
different than getting casual, drop-by comments from a reader who
merely wants to ask a question or make a note of something on the page
itself. So I think I'm going with a hybrid solution of -Talk pages for
discussion about the page, it's accuracy or it's future, and a comment
box type function for each page as well.
For the drive-by comments, it seems like the recommend method is to
include a comments page, with an editing form on it, rather than embed
the comments and form directly on the page itself. Is this still true?
The question of spam blocking always hits me in this arena. I'm no
stranger to finding captcha code places, however, I really do not like
most of it; to make things the most difficult for the bots seems to
also make things overly difficult for the user. I wonder if anyone
else has looked at alternatives to using a captcha. I was recently
pointed to http://textcaptcha.com/really which gives several reasons
why you should not use a captcha at all unless you are absolutely sure
it is necessary. The techniques they show seem really quite doable,
but I'm not sure how much could be done via recipes alone (perhaps all
of it?). I'd at least like to start working on a recipe that can
implement some of the techniques they describe (perhaps a few recipes
might be necessary, not sure) with an eye towards integrating them
into the various ways pmwiki uses forms.
At any rate, I'd like to know if others have attempted to do something
similar both with discussions and comments, and with spam prevention
that does not use captcha or require logins.
Thanks!
_______________________________________________
pmwiki-users mailing list
pmwiki...@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
John Rankin
> similar both with discussions and comments, and with spam prevention
> that does not use captcha or require logins.
I have used the honeypot technique plus a captcha (belt and braces). A
prompt that says "do not tick this box unless you are a robot spammer"
plus a checkbox field, both hidden from humans using css, strikes me as a
simple and elegant solution. The code rejects any submissions with the
field checked.
JR
--
John Rankin
Jasyn Jones
Non-floating frames all spread out to 100% of the page width.
Is there a way to make a non-floating frame that is only as big as the text within? Long sentences, wide box. Few words, narrow box.
I know I can set a % (using width= ? pct), but that doesn't solve the problem. I want something that just barely contains the text, not something that resizes with the page.
Any help would be appreciated.
- -
Jasyn Jones
jasynj (at) gmail (dot) com
"To strive, to seek, to find, and not to yield."
"Ulysses" by Alfred, Lord Tennyson
Petko Yotov
> Is there a way to make a non-floating frame that is only as big as the text
> within? Long sentences, wide box. Few words, narrow box.
Yes, you use a floating frame and then an element with a "clear" CSS
property, for example:
>>lframe<<
Here some\\
narrow text.
>><<
[[<<]]
The 'lframe' WikiStyle is included in PmWiki otherwise use float:left in
CSS. After the block, the [[<<]] line break has a clear property.
Hope that helps.
Petko
tamouse mailing lists
> Jasyn Jones writes:
>>
>> Is there a way to make a non-floating frame that is only as big as the
>> text within? Long sentences, wide box. Few words, narrow box.
>
>
> Yes, you use a floating frame and then an element with a "clear" CSS
> property, for example:
>
>>> lframe<<
>
> Here some\\
> narrow text.
>>>
>>> <<
>
> [[<<]]
>
> The 'lframe' WikiStyle is included in PmWiki otherwise use float:left in
> CSS. After the block, the [[<<]] line break has a clear property.
>
> Hope that helps.
> Petko
Stacking floats is the common way to do this, but you might also
consider using display: inline-block for your purposes.
Jasyn Jones
On Mar 10, 2012, at 7:33 AM, Petko Yotov wrote:
> Jasyn Jones writes:
>> Is there a way to make a non-floating frame that is only as big as the text within? Long sentences, wide box. Few words, narrow box.
>
> Yes, you use a floating frame and then an element with a "clear" CSS property, for example:
>
>>> lframe<<
> Here some\\
> narrow text.
>>> <<
> [[<<]]
>
> The 'lframe' WikiStyle is included in PmWiki otherwise use float:left in CSS. After the block, the [[<<]] line break has a clear property.
>
> Hope that helps.
> Petko
- -
Jasyn Jones
jasynj (at) gmail (dot) com
"To strive, to seek, to find, and not to yield."
"Ulysses" by Alfred, Lord Tennyson
_______________________________________________
Simon
tamouse mailing lists
> 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?
Peter Bowers
<tamous...@gmail.com> wrote:
> On Tue, Mar 13, 2012 at 1:11 PM, Simon <nzs...@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
tamouse mailing lists
> On Mon, Mar 19, 2012 at 10:13 AM, tamouse mailing lists
> <tamous...@gmail.com> wrote:
>> On Tue, Mar 13, 2012 at 1:11 PM, Simon <nzs...@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.
I will still be pursuing the other options listed on that link above.
John Rankin
> On Mon, Mar 19, 2012 at 2:35 PM, Peter Bowers <pbo...@pobox.com> wrote:
>> On Mon, Mar 19, 2012 at 10:13 AM, tamouse mailing lists
>> <tamous...@gmail.com> wrote:
>>> On Tue, Mar 13, 2012 at 1:11 PM, Simon <nzs...@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
Patrick R. Michaud
>
> 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.
pmwiki.org has used a couple of honeypots for a while, and it works
fairly well. On the Site.EditForm, we have
(:input hidden code1 6472:)
%comment%Enter code: (:input text code2:)
Then in local.php, something like:
if ($action == 'edit' && preg_grep('/^post/', array_keys(@$_POST)) {
if (@$_REQUEST['code1']!='6472' || @$_REQUEST['code2'] > '') {
$EnablePost = 0;
$IsBlocked = 1;
}
}
The 'code1' hidden input control verifies that hidden input controls
are being filled in and not modified by the submitter. The 'code2'
input control is the honeypot; although it's in the HTML output it
doesn't display in the browser (because of %comment%). If code2 comes
back filled in with a value, it's probably a robot of some sort.
> 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.
When I added this to pmwiki.org (several years ago), I did some logging
to see how effective it was -- it did manage to trap quite a lot of
spam submissions. However, it's not a total solution, as evidenced by
the fact that spam still manages to get past it onto pmwiki.org.
Pm
tamouse mailing lists
> On Wed, Mar 21, 2012 at 06:01:48PM +1300, John Rankin wrote:
>>
>> 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.
This was one particular option I am thinking of implementing, I am
still in the investigation phase on this.
>
> pmwiki.org has used a couple of honeypots for a while, and it works
> fairly well. On the Site.EditForm, we have
>
> (:input hidden code1 6472:)
> %comment%Enter code: (:input text code2:)
>
> Then in local.php, something like:
>
> if ($action == 'edit' && preg_grep('/^post/', array_keys(@$_POST)) {
> if (@$_REQUEST['code1']!='6472' || @$_REQUEST['code2'] > '') {
> $EnablePost = 0;
> $IsBlocked = 1;
> }
> }
>
> The 'code1' hidden input control verifies that hidden input controls
> are being filled in and not modified by the submitter. The 'code2'
> input control is the honeypot; although it's in the HTML output it
> doesn't display in the browser (because of %comment%). If code2 comes
> back filled in with a value, it's probably a robot of some sort.
>
>> 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.
>
> When I added this to pmwiki.org (several years ago), I did some logging
> to see how effective it was -- it did manage to trap quite a lot of
> spam submissions. However, it's not a total solution, as evidenced by
> the fact that spam still manages to get past it onto pmwiki.org.
>
> Pm
Thanks Pm, I thought I had read about this.
I am aware it does not get all spam, but then I think nothing really
will get all spam. They get more devious every day, sort of an
ever-escalating trade war.