Validation email links always result in Access Denied message

I have this problem as well.
I get this:

You have already used this one-time login link. It is not necessary to use this link to login anymore. You are already logged in.
Access denied
You are not authorized to access this page.

#1 when you say you disabled and uninstalled LoginToboggan, that doesn't really fix the problem we are seeing with LoginToboggan.

Any tips folks?

Settings are:

Enabled
Enabled
Set password checked
Pending user
Never delete
Immediate login checked
user/%uid/profile/profile?destination=user/%uid
user/%uid/profile/profile?destination=user/%uid
Disabled
Enabled
None

I have been trying to track this one down. It is creating serious problems with a site under development.

At first glance it appears that the problem is in logintoboggan_validate_email, as the message is triggered by a failure of the test at line 866. I put a watchdog statement immediately before this line to look at the variables and everything is OK. The problem is that the routine is being called twice, and, with user->login set on the second iteration, it fails and the message is triggered.

This is a redirection error. The user is logged in, and clicking on any page link will allow the user to navigate the site as an authenticated user. The log out function works.

The call to drupal_goto passes the correct redirect path 'user/$user->uid/edit', but drupal_goto sets the redirect destination to the original link from the email, which results in a double login attempt off of the email link.

I am still looking, but another set of eyes would be appreciated.

I am having the same problem on a 5.x site and I think I have tracked down the issue. I am using "Set password & Immediate Login" as well as a Non-authenticated role for account verification. logintoboggan_validate_email fails if $account->login is set from a user_load, which will return true if you are using immediate login.

762     if ($account->uid && !empty($account) && $timestamp < $current &&
763         $hashed_pass == logintoboggan_eml_rehash($account->pass, $timestamp, $account->mail) && !$account->login) {
            ...
826     }

To fix this I think what needs to be done is if "Set password & Immediate Login" is selected and a Non-auth role is set then don't check the $account->login. I'm working on a patch for 5.x-1.3, I'll post it as soon as I wholly wrap my head around this.

First rule of debugging: What has recently changed?

I thought it was a Drupal 6 problem. Instead it is a recent patch which uncovered a bug in the module. My watchdog entries confirm the bug.

When a user clicks on the validation link in the email, the module routes the validation through the function logintoboggan_validate_email(). After validation is done, drupal_goto() redirects the browser to the user edit page. When the browser request for the edit page returns, for some reason the request is again routed through logintoboggan_validate_email(), and it fails because the $user->login has been set.

Removing the test allows the user to use the email link multiple times, but each login is successful. The patch in #291001: Allow One Time Login To Be Used Only Once should be reversed until someone finds out why a request for a user edit page, by a logged in user, is being routed through the email validation function.

To be fair to the module developers, I suspect this might be a core problem which has shown itself with a unique circumstance. I have been all over the module code, and I cannot find any reason for it. I have checked, and the routine is not called when the user requests their own edit page, only when core redirects the browser to the page.

ok, let's handle these one at a time:

• #2: i tested locally with the exact same settings you listed, and am unable to reproduce the problem.
• #3: if you're allowing users to set their own password, then the value of $account->login doesn't matter. if it does, then you're using an outdated version of the module.
• #4: you're definitely using an outdated version of the module -- please upgrade ;)
• #5a:
  

  and it fails because the $user->login has been set.

  that would only be true if you're _not_ allowing users to set their own password -- that check is not triggered otherwise. it would be more accurate to say that _either_ one-time validation check will fail if the function is called twice.

• #5b: from all reports in this issue, it sounds like the real problem is that the validation function is being called twice. because the approach is to change the indicator for whether the validation link has been used in order to prevent multiple usage (which i believe is a sound approach), the validation would always fail the second time on the same page load, regardless of the exact logic of the validation function.

  having said that, i don't believe that #291001: Allow One Time Login To Be Used Only Once is a problem at all.

• #5c:
  

  I have checked, and the routine is not called when the user requests their own edit page, only when core redirects the browser to the page

  i'm not sure if i totally understand what you're saying here. i did set the redirect settings to user/%uid/edit?destination=contact, and it worked fine. i also tried no redirect path, and also logging out before i used the validation link. in all of my tests everything works perfectly.

can you folks please start disabling your other contrib modules to see if the problem clears up? i'm really not seeing a problem with the LT code...

Version is:
// $Id: logintoboggan.module,v 1.133.2.7 2008/12/09 23:53:47 thehunmonkgroup Exp $
running on drupal-6.10.

Settings: User can create account, no admin approval. Email verification required.

I found that when the user attempts to verify using the system generated password to log in normally, everything appeared to work properly. The problem appears when the user uses the validation link to come back in.

The links logs the user in.
The system (drupal_goto()) redirects the user to user/uid/edit.
The system re-enters the email validation, which fails the test for $user->login and prints the default message.
Processing drops into drupal_access_denied().

Browser then shows the 403 page, with the email link url still in the address bar. (Used both firefox and ie).
Click on the home page link in the header, and the site comes up normally with the user logged in.

The reason I think it might be a core issue is that the header issued by drupal goto should wipe all vestiges of the original validation link from the system, and the browser should be requesting a new page. When the same page is requested from the browser using the menu tab, without the redirect, LT is not invoked. I think the processing of the redirect is getting information from a cache and the cached information is interfering with the processing logic. Either that, or some routine might have sent output to the browser before the header() function is called by drupal_goto(). I could be way off base, but I cannot see anything in the LT code that would cause this behaviour.

Removing the test for $user->login allows the routine to be entered a second time, and the user sees normal behaviour. The patch is done for the right reasons, but it exposes this bug. Might I also suggest that

function _link_used($timestamp) {
  global $user;
  return ($user->login > $timestamp);
}

would have more general application.

I am starting a new brochure site with a fresh install of drupal6. Will play with it and see if I can reproduce the error with a lighter install profile.

i've committed a fix for #291006: Email Validate Link Landing Page -- can i get some folks to download the latest from CVS (or the next 6.x-1.x dev tarball in about 12 hours) and see if this fixes the issue?

This one is elusive. I now have two sites. Site 1 broken, site 2 working fine. Modules for site 2 a direct copy of sites/all/modules from site 1. Exactly the same suite of modules enabled and, now, fresh installs of D6.10 for each site. Loaded the 6.x-1.xdev tarball 'Last updated: March 10, 2009 - 19:11' on both installs. Site 1 broken, site 2 working fine. Thought it might be the theme and copied the site 1 theme to site 2. It wasn't the theme.

I am thinking (hoping) that I will find it somewhere in the configuration, but it is going to take a while to match each configuration item and test.

@triskelion: i think the dev tarball you have was packaged before my latest fix. maybe try with the next generated one sometime tomorrow and report back?

@plan9: can you tell us what the exact problem was with the tokens? perhaps this could result in us putting some warning in the README...

This is caused by $_REQUEST['destination'] being set to return the user to the landing page after the user finishes log in. In this case that page is an expired user/validate path.

A method to fix it is to add:
unset($_REQUEST['destination']);
After line 939 in logintoboggan.module

My issue was caused by a custom module setting $_REQUEST['destination'] during hook_user('login').

I'm setting this as fixed as plan9 seem to be fine now too.

Sorry to bring this issue up again, but it seems that the fix #14 doesn't work for me. I have made a bunch of tests (including code changes) and I always end up with this issue. Anyone else?

Thanks for the support.

Do you have any modules (either custom or contrib) that are using hook_user()? Check to see if they are modifying $_REQUEST['destination'] when $op === 'login'.

Hi Abraham. I don't have any modification of $_REQUEST['destination']. Thanks.

@Nuno Veloso: disable all of your other contributed modules and see if the problem still persists. if it does not, then start enabling your other contribs one at a time until you find the problem module.

I am running version 6.x-1.6, and am facing the same issue. I would like to try to implement the patch recommended in post #14, but am unsure where it would go in the code in this latest version.

Any help would be greatly appreciated.

To give a bit more context now that I've played around with it, it seems that the problem might be in the stage at which the user's role switches from "pre-authenticated" to "authenticated".

I took the following steps -

1. Set LoginToboggan to:
- Allow users to login using their email addresses (enabled)
- Use two email addresses on registration (enabled)
- Set password (enabled)
- Pre-authenticated role (created & enabled)
- Delete unvalidated users (never)
- Immediate login (disabled)

2. I then created a dummy user account, which resulted in an email with validation link being sent to that email address. Per the settings above, this dummy user account was not logged in.

3. I then logged in as the administrator to check on the status of this dummy account. The account *should* have been assigned to the pre-authenticated user role, since the link in the validation email was never clicked. However, the account was actually assigned to the authenticated user role.

My hypothesis is that the Access Denied error is occuring because the account is already set to an authenticated role. I am not familiar with the code in this module, so I have no way to actually confirm that, but I hope that this is helpful to someone who is better able to debug the code.
Created a new user account,

Just chiming in. I'm also seeing this behavior.
Looking at a non-validated new user, I see that they have both Authenticated User AND the pre-authenticated role assigned. Not sure if this is normal behavior, but I would assume not since having Authenticated User role would add the access we're trying to deny with the pre-authenticated role.

I'm upping this to critical since it seems to have only recently (re?)appeared in a one of the past 2 updates and is VERY confusing to users. Since I'm running it on an large scale live site, it's a major problem for me right now.

Quick follow up: Still not sure what the issue is, but the when the Redirect path on Confirmation is set to default (go to user profile) I get the Access Denied message. If I set the redirect to a custom page, that works fine. So, it's appears to be something to do with access to the user profile.

i mirrored all the settings listed in #22, and i cannot reproduce the problem.

The account *should* have been assigned to the pre-authenticated user role, since the link in the validation email was never clicked. However, the account was actually assigned to the authenticated user role.

Looking at a non-validated new user, I see that they have both Authenticated User AND the pre-authenticated role assigned.

neither of these is actually true. what you're seeing is a display issue -- core does display the greyed out 'authenticated user' checkbox on a user's edit page, but as long as the user is also in the pre-auth role, LT is dynamically removing the user's authenticated user permissions.

re: #24 -- i've also tried leaving the 'Redirect on Confirmation' setting empty, but again, i cannot reproduce the error.

time to circle the wagon, folks. i cannot fix a problem i cannot reproduce! so please, anybody who is serious about getting this issue fixed, follow these steps:

1. make sure you're running the latest stable 6.x release -- as of this posting it's 6.x-1.6
2. make use of the $_REQUEST['destination'] fix by visiting the LT settings page and verifying that the 'Override destination parameter' setting is enabled.
3. visit 'Administer › User management > User settings' and hit the 'Reset to defaults' button. then restore any settings on that page that need a non-default value. in particular, make sure the appropriate welcome emails have the correct tokens so that LT can send the validation link.
4. disable *all other contributed modules*, then see if you can reproduce the problem. i know that's not an option on many production sites, so it may require setting up a copy of it on a staging site. sorry for the extra work, but this is absolutely necessary -- i can't tell you how many times bug reports show up in my issue queue because some other contrib is not doing things 'The Drupal Way', and screwing things up.
5. if the problem is still present, please include a list of *all* LT settings and user settings, as well as a copy of one used validation link.
6. if the problem is not present with this 'clean install', then we can be pretty sure that the bug is coming from a settings error, or a conflict with another module. start enabling the other contribs one at a time until the issue reappears, and report back.

I'll try to do these tests at some point. Since my fix in $24 worked and the site is live and active, I'm not in a rush anymore.
And since the site is live and active, I'll have to clone it to a sandbox before I can step thought the list.

I had the same error as plan9. Unsetting the 'plain text email only' option in the mime mail module solved my problem (don't know why it was set). When clicking the validation link produced by !login_url with 'plain text email only' set to true, it is not completely copied in the browser's address bar, it misses a few characters causing the annoying errors as mentioned in the beginning of this thread. Certainly not a Toboggan bug.

Hope this might help others.

personally, i think LT is working just fine, so i'm putting this issue to bed for now. if somebody can follow the detailed steps in #25, and still produce the error, and provide me with detailed steps on how they reproduced it, then feel free to activate this issue again. :)

I was able to fix this issue by disabling & uninstalling Auto Assign Role. I don't know what in that module was contributing to this issue, but that fixed it for me.

For reference, I am just using the Apply For Role module to create similar functionality without causing this unwanted behavior.

For the sake of our amazing maintainers, is anyone else who is seeing this behavior also using the Auto Assign Role module?

Hey, it didn't seem to work for me either.. then I disabled/enabled autoassignrole and it works again.. weird stuff.. oh well

I'm receiving this issue as well.

upon user registration, email confirmation reset does not work and redirects to either the user/login page or 403 access denied page with the message "Sorry, you can only use your validation link once for security reasons. Please log in with your username and password instead now."

after disabling Login Toboggan - user reset links work as normal.

users are denied access upon password retrieval if they've already logged in before and already have an authenticated role (not preauth role). This patch will authenticated against password hash + password retrieval expiry length.

@SteveK: i have no idea what you're talking about here, or how your patch would solve the problem. what does password retrieval have to do with anything? and what is 'email confirmation reset'?

you most likely have a wrong token in your password reset email to the user.

I was having an Access Denied issue with the validation url and eventually pinpointed the problem to a wrong token in the email.

I changed to [user:validate-url] instead of [current-user:validate-url] and then it worked.

Hello Everyone.

I have discovered that there is an incompatibility between One Time Login Module and the Login Toboggan Module.

If you use the One Time Login Module to perform a Bulk Password Refresh, users will be forced to supply a different email than that which was validated through the One Time Login Module, which is an obvious problem.

I have extensively documented this Drupal 7 problem, along with dozens of others, at my personal website:

https://mymanthemaker.blogspot.com/2019/10/drupal-7-ubercart-7-bulk-emai...

Graham Leach