Used or invalid one-time link

Hey Chris,

Can you try the latest development release, that might fix it.

I've recently just come across this issue as well. The module script generates the custom URL, but when I go to that address on a logged out browser I get the same error. I'm currently using 7.x-1.3

I also have the same issue. I'm currently using the latest dev version.

I'm attaching a VERY lightly tested patch that covers one specific use case.

The issue is that a user can sign up and be automatically logged in, and then immediately click on the validation link in their email.

The patch assumes that we are tracking a "registered but not yet validated" user by their having the "preauthorized user" role associated with their profile.

It checks if the role exists, and acts as if the user were not logged in if they are preauth.

I don't suggest using this in production. Just hoping to assist in moving this issue forward, as I'm encountering it as well.

BTW, the logic condition in the patch I just posted is incorrect, and it doesn't actually apply either. Again, just to hopefully point somebody in the right direction.

Anyone experiencing this with 1.4? Else ill close this up.

This is still happening for me with 7.x-1.4 and 7.x-1.x-dev with Drupal 7.39

In user_registrationpassword.pages.inc on line 43 ( in "function user_registrationpassword_confirm_account()" ), why are we looking for more than one account when a single uid is being passed?

For anyone wondering, I swapped out the user_load_multiple() and its $conditions for an EntityFieldQuery()

    ...

    // Some redundant checks for extra security ?
    $query = new EntityFieldQuery();
    $query->entityCondition('entity_type', 'user')
               ->propertyCondition('uid', $uid )
               ->propertyCondition('login', 0)
               ->propertyCondition('access', 0);
    $results = $query->execute();
    if( $account = reset( reset( $results ) ) ){
        $account = user_load( $account->uid );
    }
   
    // Timestamp can not be larger then current.
    if ($timestamp_created <= $current && $account ) {

    ...

If you compare the code in core at user.pages.inc with user_registrationpassword.pages.inc, you might notice these look very similar. This is because we try to stay as close to core as possible.

But sgorneau, this has nothing to do with the current issue right? Or do you experience something related?

We are experiencing this same issue. The module works fine on a clean install, but when installed on our prod site the confirmation link sent to the user is shown as used ("You have tried to use a one-time login link that has either been used or is no longer valid. Please request a new one using the form below").

We installed the patch but it didn't resolve the issue. As of now this module is unusable and multiple users reporting this same issue so elevating Priority to Critical.

"The module works fine on a clean install"

Downgrading status again, proves it's not a bug. And you first want to provide lots more details about installed modules + trace / step debug this to it's cause + if this works on a clean install, it might be you are running logintoboggan or something and these modules are just not compatible, and can't be. Please read up on how and why.

Also:

In most cases i debugged myself i found that other modules change 'access', 'status', 'login' to not be 0.
This is the reason why user_registrationpassword does not work with some modules that also influence the registration process.
That's not a bug, it's just how drupal core works + how contrib 'has to deal with this'.

My advice always is: make sure you have no other module installed that might change any of these without knowing about them in detail.

+
If we change this, drupal core will send out default register emails again. Current code prevents core from sending out the default emails. That's why we leave/set 'access', 'status', 'login' all to 0. (or we have to replace/implement a lot of code) (leading to lots of code duplication).

+
If you have that clean install, enable all modules you have on production one by one, and try to register again, then validate the user's status/created/access. All should be 0.

And a test exists for this, and it's not failing.

Hope this helps a bit.

I am facing same problem, but when I disabled the LoginToboggan module its working fine.

I'm facing the same problem when using user_registrationpassword with email_registration module.

I found out the cause of the issue and I think that it's because of a bad API usage.

TL;DR
The module uses user_pass_rehash() in 2 places (+tests), but it's passing user's name insted of user's last login time as 3rd parameter.

According to the function's doc, the 3rd parameter is an integer, UNIX timestamp of las log in:

 * @param string $password
 *   The hashed user account password value.
 * @param int $timestamp
 *   A UNIX timestamp, typically REQUEST_TIME.
 * @param int $login
 *   The UNIX timestamp of the user's last login.
 * @param int $uid
 *   The user ID of the user account.

I am not sure if it is intended or just a mistake. The parameter name $login can be misleading.
But I think that it's a mis-use of the user_pass_rehash() function, so even if it's intended I recommend to change it to meet the spec.

I attach a patch that fixes the issue (including the test files).

This is what heppens when you use the user_registrationpassword and email_registration and set "Require a verification e-mail, but let users set their password directly on the registration form." on /admin/config/people/accounts:

1. email_registration modifies the form, it hides the username field and set a random value as default. This will be saved.

/**
 * Implements hook_form_FORM_ID_alter().
 */
function email_registration_form_user_register_form_alter(&$form, &$form_state) {
  $form['account']['name']['#type'] = 'hidden';
  $form['account']['name']['#value'] = 'email_registration_' . user_password();
  $form['account']['mail']['#title'] = t('E-mail');
}

2. user_registrationpassword alters the same form's submit handler to send out the email

/**
 * Implements submission handler for the user registration form.
 *
 * @see user_register_form()
 * @see user_registrationpassword_form_user_register_form_alter()
 */
function user_registrationpassword_form_user_register_submit(&$form, &$form_state) {

...

  $mail = drupal_mail('user_registrationpassword', 'register', $account->mail, user_preferred_language($account), $params);

3. after this, email_registraion's hook_user_insert() executes and changes the username

/**
 * Implements hook_user_insert().
 */
function email_registration_user_insert(&$edit, &$account, $category = NULL) {

...

  // Ensure whatever name we have is unique.
  $new_name = email_registration_unique_username($new_name, $account->uid);

  // Replace with generated username.
  db_update('users')
    ->fields(array('name' => $new_name))
    ->condition('uid', $account->uid)
    ->execute();

  $edit['name'] = $new_name;
  $account->name = $new_name;
}

4. When the user clicks on the activation link, the hash in the link and the hash expected by the module is different because the username has changed.

      // Else try to activate the account.
      // Password = user's password - timestamp = current request - login = username.
      // user_pass_rehash($password, $timestamp, $login, $uid)
      elseif ($account->uid && $timestamp >= $account->created && !$account->login && $hashed_pass == user_pass_rehash($account->pass, $timestamp, $account->login, $account->uid)) {

Sorry, I've uploaded the wrong patch file. Here is the correct one.

"I am not sure if it is intended or just a mistake. The parameter name $login can be misleading."

This is a bug, a mistake added in a3e4b75aa12c0f9e16f4b90bfdb29fd1e81acb24.

I'll accept the patch. Thank you very much for tracing this down Roland!

(also set the status to needs review to trigger testing next time please)