Sergiu Dumitriu wrote: > On 02/22/2010 02:28 PM, Caleb James DeLisle wrote: >> 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.
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. > 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
