uc_signup does not appear to play well with captcha, when captcha challenges are used on the user registration form.
relevant modules:
* ubercart 6.x-2.0-rc6
* signup 6.x-1.0-rc5
* uc_signup 6.x-1.0-beta4
* captcha 6.x-2.0-rc3
steps to reproduce:
- set captcha to require a challenge during user registration
- attempt to purchase a signup with a new, anonymous user
- use a credit card gateway during checkout (see PayPal note below)
- click the "Submit order" button at the "Review order" screen at the end of the checkout process (i think UC can be configured to not include this screen, in which case presumably the errors would occur elsewhere)
- checkout (and signup) do not complete; you're returned to the "Review order" screen with the following error messages displayed:
- Math question field is required.
- CAPTCHA test failed (unknown csid).
- There was an error saving attendee contact information. Please verify that you have entered all required fields at the Attendee profile contact information form
- if you're using the PayPal gateway, i believe the checkout actually works correctly, but the signup is not added for the new user
if the captcha module is disabled, checkout and signup are completed as expected.
if this was a previously unforeseen scenario, i'm not sure if it would make more sense for uc_signup to simply ignore the captcha (the user is going through an entire checkout process that a bot is unlikely to be interested in), or it'd be smart to err on the side of safety and still require the captcha.
Comments
Comment #1
ezra-g commentedThis is an interesting use case. As I understand it, you should already be able to add a captcha to the uc_signup attendees form because it has its own form id.
What's happening is that *for each attendee who does not already have an account,* we problematically submit a single user registration form. We should prevent the catpcha from being active on this form either by preventing it or removing it. On my initial search I don't see any writeups of doing drupal_execute with forms that have captchas enabled. I'll take a look around more and if not, we can fix this bug and have a blog post or documentation to share with the community.
Comment #2
ezra-g commentedWe should be able to avoid this problem with user masquerading before we do the drupal_execute. Stay tuned for a patch later today.
Comment #3
ezra-g commentedI was able to recreate and resolve the problem with this change.
Comment #4
arh1 commentedthe patch in #3 appears to fix the problem.
after applying it, i can run through the steps i outlined above and the user is created correctly. (using the payment gateways i have readily available: test credit card gateway, PayPal gateway, or the Free Order gateway provided by uc_free_order .)
i do notice that the user is created without sending a verification email even though i have "Visitors can create accounts but administrator approval is required" selected and "Require e-mail verification when a visitor creates an account" checked under /admin/user/settings . i assume this is due to the masquerading as mentioned in #2 above. off the top of my head, this seems like an area for a lot of subjectivity/interpretation (we certainly don't want to stop a user during checkout pending admin account approval, but are there ways this could be abused, or confusing to site admins?). in any event, the current post-patch behavior works great for me.
if there are any other uc_signup + profile/captcha scenarios i should test that might be related, let me know, but i'll go ahead and mark this fixed.
thanks, Ezra!
Comment #5
ezra-g commentedAnd now this is really fixed because I just committed it ;).
As for the account notification email, I think this would be a great thing to bring up in a new feature request/discussion issue in this queue. It's actually not related to the masquerading -- it's because we do
$form_state['values']['notify'] = FALSE;. There are lots of ways to change this, and in a new issue we should consider the potential results which could include one user getting an account registration email as well as several individual signup confirmation emails. How configurable should this be? Should we send a single integrated email?Comment #6
arh1 commentedha -- thanks for allowing my ESP on the issue status.
and yeah, the user registration and notification flow/configuration sounds like a good separate discussion. i think all works well currently for my needs, but i'll start a new issue if a related question/suggestion/feature-request comes up for me.