[xwiki-devs] [Proposal] Allow anonymous commenting with captcha
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? Caleb
Hi, On Mon, Feb 22, 2010 at 2:28 PM, Caleb James DeLisle < [email protected]> 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 like B. However if it's too hard to implement without breaking the need to let users without javascript do it I'm fine with A as well. Guillaume
Caleb
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki SAS Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
Hi Caleb, 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.
What about: Keep the current form. When the user clicks "Add Comment" the comment is submitted w/o using AJAX. On the server, if the current user is not authenticated then return to the client a preview of the comment with two options: (1) log in or (2) solve the captcha to add the comment. I don't know if this is doable. Thanks, Marius
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?
Caleb
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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. 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. 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. 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. 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. 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. -- Sergiu Dumitriu http://purl.org/net/sergiu/
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.
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
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
participants (4)
-
Caleb James DeLisle -
Guillaume Lerouge -
Marius Dumitru Florea -
Sergiu Dumitriu