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: >>> 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 >> > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
