CiviCRM Community Forums (archive)

Circumstance:

Membership or event registration using a profile that enables drupal account creation AND drupal sign-up form has captcha enabled using the drupal captcha module.

Behaviour

• A user that is not registered/logged in to Drupal enters details into profile as part of event registration
• Captcha field is not displayed.
• Drupal validation requires captcha field is entered, but it isn't displayed so you can't etc..
• Users become abusive

Resolution (temporary fixes for people tearing hair out)

• turn off captcha on drupal registration (=lots of spam) or
• never use a profile that enables drupal account creation or
• replace drupal registration with contribution page as membership sign up + profile that creates drupal account and use civiCRM's reCaptcha. - by replace I simply mean direct any 'create account' links to the contribution page

Long term...

It does seem a little beyond scope to have to integrate with a module contributed to drupal - where would that end?
Perhaps an easy way of replacing drupal account creation with a civicrm alternative.

And here I have gone way beyond my depth, but since I am rambling already...
 
Thinking about it the replace drupal account creation with contribution page approach is ok to a point but not so good in the light of Drupal 7 profiles as nodes approach - which gives loads of scope for social networking and so on.

It would perhaps be better to explore integrating with Drupal account creation, which could mean in effect that a profile is a node.

This may have the advantage of replacing the need for drupal-use civicrm-contact synchronisation.

Thanks Xavier, but... I've been experimenting noticed this from the helpful help bubble on the profile form next to 'include recaptcha'

reCAPTCHA is also not available when a profile is used inside the User Registration and My Account screens.

So in other words it will NOT protect the drupal user registration process from spammers -

Here's my assumption in case I have misunderstood you.

- I have a profile that has 'Drupal Registration' enabled - one and only one profile with this setting
- It does appear on the drupal registration form.

I've found some more threads on the subject and it seems that the above analysis is true... the workaround is to set up a membership / contribution page for account creation (with reCAPTCHA) enabled and redirect the drupal account creation page to that contribution page...

An elegant solution for that is offered by the Drupal Path redirect module (thanks subasmurf for that tip)

See last but one entry on this thread:

http://forum.civicrm.org/index.php/topic,7303.0.html

This is a bit nasty but it is a solution...

Problem:

path_redirect module is intended to redirect paths that don't exist to existing ones - so if you enter an existing path such as user/register it hates you. It tells you to use an alias

If you use path alias to do this the civi/contribute path is truncated at contribute - dunno why - this redirects you to a page you don't have access to and wouldn't be useful

civicrm/contribute/transact?reset=1&id=10 becomes
civicrm/contribute

Solution:

Use path-redirect to set up a redirect from register (being an internal path that doesn't exist)

edit the path_redirect table in the database using MySQL Workbench or phpmyadmin -

update path_redirect
set source='user/register'
where source='register'

note your database probably has a prefix to the table name: mysite_path_redirect

Yuk but works!

the main issue is:

civicrm calls:

        $res = drupal_execute( 'user_register', $values );

to create a user. other drupal modules can now inject fields like recaptcha etc and thus mess things up. not sure if there is an api that we can call that creates the user and does the other processing but not call the other hooks. someone can investigate how  user_import does this? (it seems to mimic a lot of the drupal account functionality)

lobo

I just ran into this issue on my site as well. It seems like kind of a big deal to me.

Same. I have found that having a two-step process of people registering an account and then subscribing to a membership via a contribution page is just too hard for them.... users! 

So I

• turned the Drupal CAPTCHA module off for the user_register form (because of this conflict)
• enabled account creation on my Contribution page profile
• set up a redirect using the Path Redirect module from /contribute to /civicrm/contribute/transact... (not sure that this is required, but I had the contribute redirect set up anyway)
• added a mod_rewrite rule for the multi-site Drupal 6 install (see below)

  RewriteEngine on
  RewriteCond %{HTTP_HOST} ^.*theonlysitetoredirect.org.nz$ [NC]
  RewriteRule ^/user/register.*$ contribute [L,R=301]
  RewriteCond %{HTTP_HOST} ^.*theonlysitetoredirect.org.nz$ [NC]
  RewriteCond %{QUERY_STRING} ^.*q=user/register.*$ [NC]
  RewriteRule ^/$ contribute? [L,R=301]

Note that I only want this feature on one of the sites in the multi-site installation, hence the RewriteCond %{HTTP_HOST}. I also have not yet enabled reCAPTCHA on the contribution page/profile. I will do that once the bots start submitting my rather complex contribution page form.

It all works really well... but it's a bit of a pain. It would be nice to see a workaround built into a future version of CiviCRM that means both forms of account registration work without serious amounts of spam registrations. The CAPTCHA module is a must have if you keep the user/registration URL open.

Mark

We would like users to be able to sign up for a drupal account independent of whether they have registered for an event or contributed. I guess the procedure is generally the same as what you and others have done. Create a CiviCRM profile to use for contact creation, allow anonymous users access to it, enable the CiviCRM reCAPTCHA on that profile, and create a redirect page for post-registraion, and add some more redirect magic to prevent direct access to the the Drupal registration page.

That is all just such an overly convoluted process for a task that should be very simple. There really should be a fix for this in core. The code that I posted above seems to work very well, and is transparent to the end user.

It allows the Drupal reCAPTCHA and the CiviCRM reCAPTCHA to co-exist. The Drupal reCAPTCHA is still used on all configured Drupal forms (including user registration) and the CiviCRM reCAPTCHA can protect event registration and contribution forms. Additionally, you can add the 'create drupal user' option to such CiviCRM forms and it just works.

Additionally, the Civi code still uses the standard drupal registration process, so all of the Drupal opt-in and verification settings are applied as expected.

I'm going to open an issue for this and submit the above code as a patch. We'll see if anything comes of it.

would be great if a few other folks can apply the patch and confirm it works for them. If so, we can apply it for the next 3.4.alpha / beta version

lobo