23 Feb
2010
23 Feb
'10
5:33 p.m.
At the moment, I'm leaning toward C
One more matter is how to turn on "anonymous commenting requires
captcha":
I think the best idea is to add a property to XWikiPreferences class
called "guest_comment_requires_captcha" then getting the parameter
using $xwiki.getSpacePreferenceAsInt so that it can be set on the
wiki and space level.
In addition, I think XWikiGuest should have to have commenting right
on a page to comment even if the property is set true so that a
single page can disable anonymous commenting.
WDYT?
Caleb
Caleb James DeLisle wrote:
Here's another possibility:
C.
Javascript filters out image and captcha entry field on ajax load
then shows them when when the user focuses on the comment field. No
extra work for the user and captchas are not displayed on every page.
Caleb James DeLisle wrote:
Sergiu Dumitriu wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
On 02/22/2010 02:28 PM, Caleb James DeLisle
wrote:
blogger.com
makes the user click on a link to see comments and the comment form and captcha are loaded
then.
funnyjunk.com uses exactly method A.
Guests should be allowed to comment on a page but
we still want to avoid automated
comment adding and captcha is a solution which already exists.
If a captcha is displayed on each comment form which shows at the bottom of each page
then each page load will require the generation of a captcha which will hurt
performance.
A.
When the user is anonymous, don't show the comment form, instead show a link
"Add Comment" and load the form and image through ajax.
This would not be a major change since anonymous users currently don't see the
comment form.
B.
Display the form but strip the 'Add Comment' button and force the user to preview
the
comment and load the image with the preview button. Of course the behavior must be
different when users don't have Javascript and they are viewing the comments through
"?viewer=comments" so there would have to be some means of detecting how
commentsinline
was being loaded.
In order to keep the core from becoming dependent on the captcha module, the commentadd
action will have to be duplicated in commentinline.vm I see no other way around it.
Any other ideas?
I don't like either of these approaches, mainly because it
involves an
additional step. We're making the process cumbersome for the user just
because we're trying to mask performance issues. No other public site
I've seen does it this way, and perhaps there's a reason. A guest that
wants to comment is (most times) doing an unpaid favor to the author. If
the author makes this process difficult, then the user will take his
comment away and find another site. And we don't want that.
Captchas are by
their nature unnecessary difficulty but everyone seems to like them better than other spam
prevention techniques.
First, I don't agree that guests should have
the right to comment by
default. The default rights should be the same as they are now. And it
is easy to enable comments for guests.
I meant it should be configurable, I agree
default should be same as always. Sorry for unclear wording.
The only thing that would need to change is that
when guests can
comment, beside the new comment form the captcha image should be displayed.
Can you point to a site which does this?
Is there really a performance issue? Our target
market (intranets) don't
need this at all, since all users must be logged in to even view a page.
There are very few public sites based on XWiki that allow guest
commenting, but we still should care about those.
So, there is a performance problem, but it should be handled differently.
On a really busy server, where clustering is needed, then the best
approach would be to have a distinct server for generating images, which
should be used by all the XWiki servers. One step would be to make sure
that this use case is supported by our captcha module.
Why not use clustervm?
If the image generation process is inside the
wiki server, then there
are other few improvements that could be implemented. Here's a possible
approach:
- the images are not generated synchronously on demand, but are
generated in a separate thread and pushed into a pool of tests (image +
solution); I'm thinking a queue with a fixed size QS and blocking pull/push
- when a thread needs a new image it takes it from the pool (blocking
until an image is generated if none is available)
- images are not automatically consumed once used, they are pushed back
in the queue, except if:
a) it was solved
b) it was attempted NA times without being solved
c) it was displayed ND times without being attempted/solved
If QS is large enough, users won't notice that the same image is used.
This will help reduce the load since not all requests will require a new
image, and the proper configuration would still make this effective.
Of course, QS, NA, ND should all be easily configurable. Some defaults
from the top of my head: 300, 3, 10.
This seems like a lot of work for something which you yourself said will not be
commonly used.
It also sounds like it should be implemented in jcaptcha since jcaptcha has a
CaptchaService
which gives out puzzles for id strings and then accepts solutions with the same id
strings.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs