22 Feb
2010
22 Feb
'10
2:28 p.m.
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
22 Feb
22 Feb
2:48 p.m.
Hi,
On Mon, Feb 22, 2010 at 2:28 PM, Caleb James DeLisle <
calebdelisle(a)lavabit.com> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Lerouge
Product Manager - XWiki SAS
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
3 p.m.
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5:24 p.m.
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/
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.
7:55 p.m.
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:
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
23 Feb
23 Feb
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
5319
days inactive
5320
days old
6 comments
4 participants
participants (4)
-
Caleb James DeLisle -
Guillaume Lerouge -
Marius Dumitru Florea -
Sergiu Dumitriu