Skip Comment Preview CAPTCHA
nicholasThompson - February 5, 2007 - 09:17
| Project: | CAPTCHA |
| Version: | 6.x-2.x-dev |
| Component: | User interface |
| Category: | feature request |
| Priority: | normal |
| Assigned: | soxofaan |
| Status: | closed |
Description
I just noticed that if you force a user to preview their post before posting it - the preview comment window doesn't appear to have the captcha field.
Does anyone else experience this issue?
#1
yes. i'm surprised to not find writeups about it. it seems that if captcha validation passes, the field is not added to the form. since there was a captcha field on the preview form, it does pass validation, and so is not displayed again. but then the submission of the form under the preview fails, because now there is no captcha field. i have no good ideas on how to work around this problem.
#2
The effect is opposite in 5.x-3.x-dev. The user is presented the CAPTCHA on both initial form and preview form. Although there is an option to skip the CAPTCHAs completely once the user has submitted a form, it would be nice to give the option to skip the CAPTCHA on the preview form for that one comment.
#3
Here's a try at solving this. It seems to work in limited testing. What it does:
* The CAPTCHA won't appear on the initial comment form
* The CAPTCHA does not need to be filled-in if the user previews the comment even when the Post comment button is available
A similar solution could be adapted for nodes.
#4
Using something along the lines of:
<?php/**
* Implementation of hook_form_alter()
*/
function hook_form_alter($form_id, &$form) {
if ($form_id == 'comment_form') {
// Remove extra post commment button, as it makes it harder to see the captcha
unset($form['submitextra']);
}
}
?>
is a nice touch, too. When previewing a comment, there's two post buttons and this disables the first, so the captcha is more obvious.
#5
I'd like to note something important about comments and previewing.
Comment previewing is just a user oriented feature to force people reading their submission a bit before real submission. When "Preview comment" is set to "required", this "requirement" is only in the user interface: there is only a "Preview comment" button on the comment forms and no "Post comment". Spam bots (who do not use the user interface) however can post directly without the need for previewing, since there is no hard requirement in the processing that a comment should be previewed before submission.
If you're on linux (or mac osx too, I guess), you can check this for yourself. Make "preview comment" required, make sure anonymous users can post comments and run something like the following wget command:
wget --post-data "subject=spam&comment=spamspamspam&op=Post%20comment&form_id=comment_form" --no-directories http://example.com/?q=comment/reply/11(use the right url of a comment form of you set up of course). This will post a spam comment directly without any previewing in the mix.
The trick is the "op=Post%20comment" part: in the user interface there is no button with "Post comment", so human users can't post with "op='Post comment'" through the web interface, but if you have more control over the post data (like spam bots), you can do it.
This should be taken into account very carefully for this issue, so that we won't make it easier for spam bots to submit ;)
Another thing to consider/discuss: should the CAPTCHA only be solved for the first preview pass and not on following passes (this is already possible with CAPTCHA module 5.x-3.0) or should the CAPTCHA only be solved for the final post (like in the patch from #3)?
I think the former is better. Take for example a situation where the user wants to preview several times. With the former approach (s)he has to solve a CAPTCHA only the first time. With the latter approach, the user has to solve a CAPTCHA each time except the first time. The patch from #3 tries to address this by skipping the CAPTCHA check for previews, but this is hard to explain to the user (explaining CAPTCHA is already hard). Another advantage of the former is that spambots are blocked sooner so that less resources are spent on spam.
To wrap up, I think this isn't a bug, since it is already solved (see persistence on the CAPTCHA settings page).
The patch from #3 is more like a solution for a feature request "only CAPTCHA for final post". I'd like to see more reasons why this would be needed/a good idea. The code also needs some work (e.g. more explanation to users and to make it compatible with node previewing too, as suggested in #3).
#6
Thank you for clarifying how previewing works. I'd like a user to solve a captcha every time they post a comment, but only once per comment. There's currently no way to do this with the captcha module.
#7
My five cents.
You may want to take a look into this patch. It adds desired CAPTCHA mode "Omit challenges for the form instance once the user has successfully responded to a challenge for that form instance.".
Basically it means that if after form is rendered and before it's submitted (previews don't count as submits) user has solved CAPTCHA it won't be shown again. It will be shown after form is submitted however.
This patch haven't gone through deep testing but appears to be working. Any comments and maybe even inclusion in CAPTCHA module itself will be appreciated. :)
#8
#9
Nice! Works as I want and would expect. The option description is a bit hard to understand, but that's the only problem. Maybe something like, "Require user to respond to challenge once per submission." The others could probably be reworded too, though.
#10
I agree, that would be much better than "form instance". And I agree that the meaning of other options is hard to understand by their labels too. Maybe you will propose labels for rest three?
#11
It does not work for me.
It does not implement the feature as requested in #6.
It works just like the already available option "Omit challenges for a form once the user has successfully responded to a challenge for that form."
The reason for this is that the patch from #7 uses $form['#token'], which is not unique for authenticated users and it doesn't even exist for anonymous users.
I'll work on a better patch.
#12
Much to learn in Forms API. I'm curious how to implement this patch correctly. Will $form['#build_id'] do a better job than $form['#token']?
#13
@soxofaan: It does work here according to the way I'd like and described in comment #6. I'm not sure why we're seeing different things. *shrug*
#14
at #13:
scenario with patch from #7 + comment form + anonymous user:
so far so good, now we'll enter a new comment
This is the already existing "Omit challenges for a form once the user has successfully responded to a challenge for that form."-behaviour.
This is not as requested in #6: for each new comment/entry/submission one should solve a CAPTCHA.
#15
I already spent some time on researching/writing a solution, but it seems more difficult to solve than one would expect on first sight. I have some code that comes close, but I'm not happy with it because it's spread out in different parts of the code, it's hackish, it makes understanding/maintaining the module harder, etc. Spaghetti code in short.
Note that the CAPTCHA module is already hard to understand (usage of sessions, pre_render hacks, ...). The big problem is that you just can't skip CAPTCHA specific processing like with the other persistence modes. During "skipping" you still need to do some CAPTCHA housekeeping with session variables and hidden form elements for example.
I propose to postpone this feature request for Drupal 6, where the new Form API should make this feature easier/cleaner to implement.
There are already useful persistence modes available, so I think this feature request is a minor issue after all.
Any thoughts?
#16
@soxofaan
I propose to slightly modify my patch so that behavior was as follows:
1. Registered users solve CAPTCHA only once per form submission.
2. Anonymous users solve CAPTCHA every time (this is more strict than in #8 and closer to real-life IMHO).
Since there are really many cases when anonymous users can only read, not create nodes or comments, this will probably make many people happy.
#17
@#16:
That would make it even more complicated ;)
I'm not a big fan of differentiating CAPTCHA between anonymous users/registered users/user roles. If you don't trust a user, which means in this case that there is a possibility it is a (spam)bot, does it matter that he is anonymous or logged in?
Why do you need a CAPTCHA for anonymous users then (except for registration maybe)?
#18
@#17
I don't need CAPTCHA for anonymous users, that's why I didn't bump into problem with them. I'm just thinking that maybe I'm not quite alone.
Another approach would be to identify forms by $form_id for anonymous users and by $form_token for registered users. So this will work uniformly for everyone: one submission - one CAPTCHA. This has a limitation however:
1. Anonymous user (A) enters comment on node A and previews it.
2. (A) enters comment on node B and see that there's no CAPTCHA. Oh that's fine.
3. (A) submits one of comments.
4. When (A) tries to do anything with the other one he sees 2 messages:
1) Invalid CAPTCHA token (Oh!! What's that?!);
2) Please solve CAPTCHA (oh, that's okay).
I don't see sense in telling user about 'Invalid CAPTCHA token'. Maybe just write this message to log if CAPTCHA errors are being logged?
Anyway, users do such things as simultaneously previewing several comments rarely, so most of them will have better experience. Imagine several-screen form when you have to solve CAPTCHA every time you make an error on want to preview - that's terrible experience.
#19
#7 asbeta - thanks, I appreciate your patch.
#20
Hi!
I'm quite new to drupal, so forgive me if this idea is nonsense.
Can this problem be solved by creating a page that only has the captcha field, and using pageroute to link the actual node submission page and this one with the captcha field?
If it works, I guess it would add the benefit to clear the node submission page a little bit.
Regards,
Carlos.
#21
So there is no easy way to do what #6 requested, in the current 6.x-1.0-rc2?
"Request a user to solve a captcha every time they post a comment, but only once per comment."
#22
This is solved (for a long time already) in the CAPTCHA 6.x-2.x branch in a much cleaner way than could be possible in the 6.x-1.x branch.
I think it's best to mark this (outdated) thread as fixed now.
If there would still be interest in the other suggestions in this thread, please reopen.
#23
Automatically closed -- issue fixed for 2 weeks with no activity.