22 Feb
2010
22 Feb
'10
7:37 p.m.
Sergiu Dumitriu wrote:
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.