Receiving random "pending admin approval" requests

I've seen the same thing happening, and also don't require admin approval etc.

I've seen it happen too. Mine came from an actual user who registered. My site also doesnt require approval. other users have registered previously without this email notification. Not sure what triggered this one. Any clues?

Account details for vicman at MySite.net (pending admin approval)

vicman has applied for an account.

http://www.mysite.net/user/%252Fedit

Just want to add that we are also seeing this same issue and don't understand where or why it is being generated. These are actually users in our system however, we can search for users and find them in the list of users.

One of our clients has experienced this as well.

For what its worth - this appears to be generated by function user_register_submit. There's some logic, let me see if I can figure it out ...

  if ($account->uid == 1) {
    // User 1 being created
  }
  else {
    if ($admin && !$notify) {
      // An administrator creating an account (without email notification)
    }
    else if (!variable_get('user_email_verification', TRUE) && $account->status && !$admin) {
      // No e-mail verification is required, account is not blocked, and isn't being created by an admin
    }
    else if ($account->status || $notify) {
      // Account is not blocked, OR being created by an administrator with 'notify' set
    }
    else {
      // Create new user account, administrator approval required.
      $subject = _user_mail_text('approval_subject', $variables);
      $body = _user_mail_text('approval_body', $variables);
      // ......
   }

.. So the approval mail fires if the user being created is not user 1, it's not being created by an administrator (i.e. is a visitor registering themselves), and the account is not blocked - or, more accurately, $account->status resolves to false. I wonder if it's possible for $account->status to resolve to false in other circumstances? Could it be somebody trying to attack the user registration page somehow?

BTW - mine is under Drupal 5.15.

Bumping this issue as we are continuing to experience it.

It would appear that the corresponding user is also receiving an email (as one would expect, since it's in the same code block identified above).

The user's approval mail is being fired without a user id (as above). In addition, oddly, the !username variable appears to be mangled as well - the username in question is XXX.YYY@NNN.com, and !username is being displayed as "XXX". Here's the text of the email, ALLCAPS are mine to protect the innocent:

XXX,

Thank you for registering at SITENAME. Your application for an account is currently pending approval. Once it has been granted, you may log in to http://www.EXAMPLE.com/user using the following username and password:

username: XXX
password: PPP

You may also log in by clicking on this link or copying and pasting it in your browser:

http://www.EXAMPLE.com/user/reset/%252F1236962843/11476dd21eb0fd236a78302627124166

This is a one-time login, so it can be used only once.

After logging in, you may wish to change your password at http://www.EXAMPLE.com/user/%252Fedit


--  SITENAME team

Okay, I *thought* I've got this narrowed down to the fact that somebody had duplicated the user registration form on a url other than user/register (unbeknownst to me). Apparently the _user_edit_validate() function uses arg(1) to decide how to validate the contents (presumably on the assumption that this will always be done at 'user/register', 'admin/user/...' or 'user/XXX/edit').

In my opinion that's an incredibly dangerous way of differentiating between "attempted registration" and "account edit", as if this form is invoked anywhere other than "XXX/register" it sidesteps some of the 'already exists' validation:

  if (user_access('change own username') || user_access('administer users') || arg(1) == 'register') {
    if ($error = user_validate_name($edit['name'])) {
      form_set_error('name', $error);
    }
    else if (db_num_rows(db_query("SELECT uid FROM {users} WHERE uid != %d AND LOWER(name) = LOWER('%s')", $uid, $edit['name'])) > 0) {
      form_set_error('name', t('The name %name is already taken.', array('%name' => $edit['name'])));
    }
    else if (drupal_is_denied('user', $edit['name'])) {
      form_set_error('name', t('The name %name has been denied access.', array('%name' => $edit['name'])));
    }
  }

So, user_validate_name and drupal_is_denied are only called if the current user has certain permissions (which an anon user won't have) or they're at XXX/register.

I figure this still doesn't class as "critical" since it doesn't prevent the normal operation of the module, but it could still be problematic if any well-meaning developer tries to create a custom registration procedure. Or - heaven forfend - puts the reg form into a block. My brain is not big enough to chase the code through all the potential problems if somebody were to submit a user edit form at node/1.

Well, anyway, I tracked the problem down to that and moved our custom registration form to XXX/register.

Unfortunately, somehow the error has now recurred.

This does not invalidate the notes above - it just means there's something else causing one validation or another to not be called. Or maybe to accept something that should fail. How does user_validate_name() work...? Hrrm...

Could it be the result of somebody clicking the 'Create Account' button twice?

The issue appears to be related to a user using capital letters to start his or her user account. If a user with the same user name tries to register but does so with a capital letter, then it circumvents the normal validation method and triggers the admin approval pending status.

If you go into the database and look at the watchdog table you can see that.

We're experiencing the same problem. We have both "Visitors can create accounts and no administrator approval is required" and "Require e-mail verification when a visitor creates an account" selected, and the registration form is added via drupal_get_form('user_register') to a page created using the front_page module.

The only way I have been able to replicate it so far is when I try to register with a username that has already been taken by a user on our site. Ideally it should generate an alert saying that the username is already taken, but instead it triggers the "pending admin approval email". Btw we're on drupal 5.7.

@pbriggs: The system uses arg(1) for some of its logic, so using drupal_get_form('user_register') to display the form at a URL other than '[XXX]/register' will definitely cause problems. See #9 above.

You could maybe use a hook_form_alter to change the #action of the form when it's on the front page? If the form submitted directly to user/register (instead of the usual drupal behaviour of submitting to itself for validation / processing and then redirecting on) then that's where the form contents would be processed...

@kingandy: I saw that the last post is from April 27.... Did you find a fix in the meantime?

Same issue for me as well, on a D5.19 install. I have it since march 2008, but I didn't really pay attention to it. I thought it's about time to look into it.

Same for me!

I am also getting this on D5.20

I have been getting it for months now. Would be nice to resolve this...

This is caused when by a race condition in user_register_submit. In certain cases, when a user submits the data twice (e.g. duble clicks the submit button) and Drupal process in parallel the user_register form with the same data. In certain (unlucky) case, when the forms processing runs (almost) in parallel, you will get:
* different PHP instances call user_register_validate which checks that the username is not used. Both instances say that its not used and Drupal moves on to user_register_submit
* different PHP instances call user_register_submit with the same data, which calls the user_save function
* different PHP instances try to do INSERT INTO {users} ... . This is when MySQL keys come into play and stop different accounts (with the same username) to be created. The first PHP instance succeeds and returns the user object. The other(s) fail and return false.
* from now on, if you follow the user_register_submit logic, you'll see that if ($account->status || $notify) is true for one PHP instance (and the password link email are sent to the user), and false for the others (because $account is false) and the notification email is sent to the admin.

How you can check I'm right:
1. the email the administrator receives has a broken user edit link (caused by '!edit_uri' => url('user/'. $account->uid .'/edit', NULL, NULL, TRUE) and $account being false)
2. the account is created with uid X, and from the users table there's a missing uid next to X (before or after it). The missing uid was generated by user_save, but the insert was denied by MySQL.

I'm not sure if this happens when the site is more busy or less busy. For me happens about 2-3 times/month. Considering my research, I simply ignore the emails because I know the user actually got his/her account setup.

How to fix this:
1. in JavaScript, disable the submit button after the first submit
2. in user_register_submit, if user_save returns false, skip all the rest.
3. in user_register_submit, the last else should be else if($account) { instead of else {

Cheers,
Andrei

Btw, I just looked into Drupal 6.16 code and this was fixed. On line 2342, you'll find:

  $account = user_save('', array_merge($form_state['values'], $merge_data));
  // Terminate if an error occured during user_save().
  if (!$account) {
    drupal_set_message(t("Error saving user account."), 'error');
    $form_state['redirect'] = '';
    return;
  }

Maybe, you can back port it. Maybe, it's too late ;) D7
Cheers,
Andrei

I have Drupal 6.20, User Management -> User settings: Visitors can create accounts but administrator approval is required + Require e-mail verification when a visitor creates an account.

I'm still receiving Account details for XYZ at domain.tld (pending admin approval) emails once or twice a week.

Considering the lack of activity on this issue and that Drupal v5 is no longer supported by fixes or patches, I am going to close this ticket. If this issue still exists and you want to continue to ask for technical support from the community, please reopen and update this ticket.

thanks all...I had a same issue. Code is really helpful for me.

And now there is no spam or email notification form anonymous users that they want admin approval.

Hi all, I am receiving the same email messages now in Drupal 7.41 ,Do we have any work around for this.Please let me know how can I fix the issue.I need to stop the emails being sent to the Admin with the subject pending admin approval.Thanks in advance.