3

I don't like that Drupal 7 exposes at the registration page whether the provided e-mail is known by displaying a "The e-mail address [email protected] is already registered. Have you forgotten your password?" message.

I would prefer if it only lets the user know that the process has been initialized, and depending on the status of the e-mail it either sends out a normal registration e-mail or a password reset.

What would be the best way (the closest to Drupal's philosophy) to implement such a feature?

Is this a module?

Could it be accomplished by reconfiguring the fields of the user account?

3
  • Drupal 6 or Drupal 7 ?
    – GoodSp33d
    Jul 24, 2012 at 14:16
  • Drupal 7. I've edited the question, thanks for bringing this to my attention. Jul 24, 2012 at 14:32
  • 1
    Note that, as often, there's a conflict between security and usability. There is also the password recovery tab, as mentioned by @kiamlaluno, which tells you whether the submitted username/e-mail exists or not. What do you want to with that? "Maybe your entered e-mail address exists so maybe we sent a mail to you." ? ;)
    – Berdir
    Jul 24, 2012 at 19:15

3 Answers 3

4

If you want to change the way a user can register on a Drupal site, I would rather implement hook_menu_alter() to alter the menu callback called when a user access user/register.

function mymodule_menu_alter(&$items) {
  if (isset($items['user/register'])) {
    $items['user/register']['page arguments'] = array('mymodule_register_form');
  }
}

If you are going to allow users to enter an email that is already used from another account, then you should alter also the menu callback associated with user/register, as Drupal allows users to reset a password by entering their username or their email address.

screenshot

function mymodule_menu_alter(&$items) {
  if (isset($items['user/register'])) {
    $items['user/register']['page arguments'] = array('mymodule_register_form');
  }
  if (isset($items['user/password'])) {
    $items['user/password']['page arguments'] = array('mymodule_user_pass');
  }
}

The functions Drupal uses as form builders for those menus are user_register_form(), and user_pass(). You can use them as guideline for the code you implement.

Keep in mind the following points, though:

  • The unique email is necessary because Drupal allows users to request a new password by entering the email associated with their account. This is also helpful for who simply forgot their username, as the email sent from Drupal contains a link that redirects them to their account, where they will eventually change their password (or just enter their previous password to keep it).

  • There isn't any security involved, as that doesn't allow a user to know all the emails used in a Drupal site, nor any email matching a partial email address. The users need to enter a complete email, and at that point there is few they can do; even in the case they try resetting a password, Drupal would sent an email to that email address, to which that user needs to have access. If that user can change the password of that email address, or can obtain it, that is not a Drupal security issue, but eventually with how that email address is handled, or who knows the password used for an email address.
    If there is a security issue with allowing to use an email address to reset a password, then there would be a security issue even in the case the user is able to enter a username to request a new password, because somebody could find out a username already in use on a Drupal site.

  • Allowing to have not unique emails can create problems with modules such as the LoginToboggan module that allows users to log in entering their email address when logging in. There are probably other modules that assume there aren't two user accounts using the same email.

  • Enforce unique email addresses for users is a Drupal issue report related to what you are trying to achieve. If this patch is going to be applied, it will be possible to allow users not to have unique emails by setting the user_mail_unique Drupal variable.

3
  • 1
    I like a lot of what Kiamlaluno has said here, so rather than provide an alternate answer I'll add a +1 for this and suggestion: if you want to hide information about your users then you probably also need to try to identify and prevent the ways to find which usernames are registered drupal.org/project/username_enumeration_prevention is a module that tries to do that.
    – greggles
    Jul 24, 2012 at 22:52
  • @greggles, what makes the menu alter method preferable over form altering the submit and/or validation on the user forms? I may be missing something, but don't a lot of third party module rely on the exiting form names for adding functionality?
    – mpdonadio
    Jul 25, 2012 at 0:15
  • @MPD that's probably a good point that these pages should use the same forms to allow third parties to continue to modify them. Drupal's access/validation system is quite inconsistent, but in the case of user operations I would say that access/validation should be added via related hooks rather than to forms. Hooks should always be called even if login happens via a different form.
    – greggles
    Sep 28, 2012 at 14:00
3

Yes, you can alter the form and replace the validate and submit functions with your own. You want to alter user_register_form(), which uses user_account_form_validate() as the validate and user_register_submit() as the submit callbacks.

You have to copy these two functions and then adjust them as you want. Basically, in the validate function, remove the form_set_error() and add the same check in submit instead, where you use the functionality of user_pass_submit() to send the mail.

0

I would look at function yourtheme_form_user_register_form_alter(&$form, &$form_state, $form_id)

and the associated functions.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.