Duplicate Email confirmation is bypassed when registered user is moderated by spam check

K a M a L

Well-known member
Affected version
2.1,2.2
Most forum owners require email confirmations because they don't want users registered with fake emails and a lot of forums require both email confirmation and admin approval .. currently xenforo handles this incorrectly
spam check on registration service can set user state to moderated, in this case setInitialUserState() won't do more processing
Code:
protected function setInitialUserState()
{
   $user = $this->user;
   $options = $this->app->options();

   if ($user->user_state != 'valid')
   {
      return; // We have likely already set the user state elsewhere, e.g. spam trigger
   }

   if ($options->registrationSetup['emailConfirmation'] && !$this->skipEmailConfirm)
   {
      $user->user_state = 'email_confirm';
   }
   else if ($options->registrationSetup['moderation'])
   {
      $user->user_state = 'moderated';
   }
   else
   {
      $user->user_state = 'valid';
   }
}
and user will be moved directly to approval queue without confirming email ..
 
Yes this is a known design issue and has been discussed many times in the past.

The issue is mostly mitigated with email bounce handling because an invalid email will cause their account to be blocked until verified.

There may be different approaches we take in the future.
 
well, I think it is a clear bug that can be easily fixed so I don't see any reason to leave it for the future .. but it is your decision anyway
 
The issue is mostly mitigated with email bounce handling because an invalid email will cause their account to be blocked until verified.
This does not help when the given email address exists and belongs to another person (who then complains rightfully that you are sending them email although there has never been a double-opt-in).
 
This "security issue" can be simply fixed by by creating a new user_state email_confirm_moderate which would move the user to moderation queue after confirming email .. such trivial change shouldn't be considered a "design issue"
 
Top Bottom