Optionally disable login capability for pre-auth users

BTW we've used something like this in our custom contrib user_login_authenticate_validate replacement:

// logintoboggan disallow incomplete logins
  if (module_exists('logintoboggan')) {
    $id = logintoboggan_validating_id();
    $in_pre_auth_role = in_array($id, array_keys($account->roles));

    if ($in_pre_auth_role) {
      form_set_error('logintoboggan-role', t('Your registration has not completed yet.'));
      logintoboggan_resend_validation($account);
      return;
    }
  }

We additionally would need to check the setting and add it to the admin form.

Reactivating once to try explaining the clear need:

A user that is not validated should really not be able to login.
We're encountered many problems with other modules in (loggedin) preauth role state. First of all, users really think they're authenticated and the registration was passed finally. They think "OK, i'm in, so the registration process must have been completed". They tend to ignore the activation mail. And they finally also don't understand why there's some limited functionality at some point - since they see they're loggedin. Indeed already two customers (their administration team) where unable to understand the idea of being logged-in even if not yet validated.

On a big site it is very complex to setup the special pre-auth role. All/Some permissions you allow to a authenticated user need to be added to the pre-auth role. You also need to check the site functionality twice -- once for registered, once for pre-auth. The application complexity is becoming bigger.
We're encountering problems with modules that don't show some features due to missing authenticated role. Sure this is a bad implementation (because they rely on the authenticated state instead of a permission.. in fact i was unable to identify all sources of this mess on a huge platform...) but we can be much more failproof from LoginToboggan point.

Simply allowing to drop this intermediate login state makes many things easyer.

So i see this extension as a process/state simplification feature.

Providing modified version of our setup for D6.

Note that the login happens in the validation function.
If we append this in the validate stack we're doing something wrong. See user_login_final_validate stating "Should be the last validator".

You might need to scan for the right position or unshift at the very beginning.

Finally what we're doing is replacing the user_login_authenticate_validate function since this shouldn't be executed if this earlier rid validation fails.

Also we're resending the email each time a user tries to login with not-yet-validated credentials.

<?php
function prevent_pre_auth_login_form_alter(&$form, $form_state, $form_id) {
  switch ($form_id) {
    case 'user_login':
    case 'user_login_block':
      $key = array_search('user_login_authenticate_validate', $form['#validate']);
      $form['#validate'][$key] = 'prevent_pre_auth_login_validate';
      break;
  }
}

function prevent_pre_auth_login_validate($form, &$form_state) {
  // pre-auth check (logintoboggan.module)
  if (isset($form_state['values']['name']) && $form_state['values']['name']) {
    if ($account = user_load(array('name' => $form_state['values']['name']))) {
      $validating_id = logintoboggan_validating_id();
      if ($validating_id != DRUPAL_AUTHENTICATED_RID && in_array($validating_id, array_keys($account->roles))) {
        form_set_error('name', t("You cannot log in until you have validated your user account"));
        // resend validation email
        logintoboggan_resend_validation($account);
        // terminate login processing
        return;
      }
    }
  }

  // regular drupal authentication_validate check
  // this doesn't set errors for wrong password submissions!
  user_authenticate($form_state['values']);
}
?>

A tiny step forward.

Added a maintainable project (currently only D6) for this functionality due to contact requests and our usage in multiple modules.
http://drupal.org/project/logintoboggan_prevent

I'm also open to add a D7 version if this is the preferred way.
We can then check the stats and have data to decide if this is a commonly used LT feature.