Resetting priority level according to our documentation https://docs.joomla.org/Priority

thank you for providing such detailed instructions

I followed them and could not replicate the issue

Can't replicate either.

All I can suggest is to try reproducing this issue with two super admin accounts, even though I only had one.

Retested as requested with two super admin accounts
I still cannot replicate that a user who has not been enabled/activated by an admin can log in

Closing as two experienced testers wouldn't reproduce it.
Feel free to open a new issue if you can provide step-by-step instructions on a clean, newly setup Joomla installation.

Experiencing exactly the same issue. I've found numerous reports of the same problem when trying to find a solution, and all I can find is users being fobbed off because 'experience testers' cannot replicate. When will this be looked into seriously?

I have exactly the same problem.
I'm on Joomla 3.4.8 / PHP 5.6 and also have 2 administrators set to receive system emails.
I also observed that the user options randomly lose the settings for Account Activation (set to Administrator) and Notifications mails (set to Yes)

Screenshot of lost setting:

Can you post the contents of the params field in the #__extensions table for the com_users row - that is where the setting is stored. However in my tests right now if I remove the setting from the param then it falls back to the default setting in the xml file which is yes. I cant find anyway in an unmodified joomla for the setting to disappear completely

I have spent today dealing with exactly the same issue on one of my sites. The odd thing is the exact same site (fresh Akeeba copy) works perfectly on the test host, but not on the client's production host.

The dev site that works is PHP 5.3.32. The production site that does not is PHP 5.4.45 The database at both sites has latin1_swedish_ci collation. Both sites have the same multiple super admins, and the problem occurs (or does not occur) no matter how many of those are marked to receive system emails.

On the copy of the site that works (PHP5), the state of the users table row changes as follows:

• User registers, row created: block=1, activation=some token string, params={}
• User gets email and clicks on verification URL: block=1, activation=some new token string, params={"activate":1}
• Admin gets email and clicks on activation URL: block=0, activation=no string, params= {"activate":0}
• User receives account activated email

On the copy of the site that does not work, the state of the users table row changes as follows:

• User registers, row created: block=1, activation=some token string, params={}
• User gets email and clicks on verification URL: block=0, activation=no string, params={"activate":0}
• User immediately gets Account Activated email
• Admin gets email and if attempts to click activation URL gets "Registration failed: Verification code not found." message

It's almost as though somehow the process is seeing that initial ?task=registration.activate&token=whatever response from the user email as one coming from an admin email instead.

Should have mentioned I am at 3.4.8

And dev site that works is 5.5.32 not 5.3.32

What it looks like is that the user verification process is somehow driving the process twice in the site that's not working correctly.

I added some basic error_log debugging to three programs in com_users

Here's the flow through those programs in the site that works correctly:

• user registers via form 03-06-2016 19:15:55.773700 mytestsite.com/components/com_users/controller.php load model registration 03-06-2016 19:16:34.290200 mytestsite.com/components/com_users/controller.php load model registration
• user clicks on email verify link 03-06-2016 19:17:58.646500 mytestsite.com/components/com_users/controllers/registration.php before 'attempt to activate the user' 03-06-2016 19:17:58.648500 mytestsite.com/components/com_users/models/registration.php entry of function activate 03-06-2016 19:17:58.648500 mytestsite.com/components/com_users/models/registration.php 'user is verifying their email' 03-06-2016 19:17:58.915100 mytestsite.com/components/com_users/controller.php load model registration
• admin clicks on their email activation link 03-06-2016 19:20:51.796000 mytestsite.com/components/com_users/controllers/registration.php before 'attempt to activate the user' 03-06-2016 19:20:51.798000 mytestsite.com/components/com_users/models/registration.php entry of function activate 03-06-2016 19:20:51.798000 mytestsite.com/components/com_users/models/registration.php 'admin is activating the account ' 03-06-2016 19:20:52.069500 mytestsite.com/components/com_users/controller.php load model registration

Here's the flow through those programs in the site that works wrong:

• user registers via form 03-06-2016 19:34:14.224500 mylivesite/components/com_users/controller.php load model registration 03-06-2016 19:34:57.405800 mylivesite/components/com_users/controller.php load model registration
• user clicks on email verify link 03-06-2016 19:38:53.888200 mylivesite/components/com_users/controllers/registration.php before 'attempt to activate the user' 03-06-2016 19:38:53.889700 mylivesite/components/com_users/models/registration.php entry of function activate 03-06-2016 19:38:53.889700 mylivesite/components/com_users/models/registration.php 'user is verifying their email' 03-06-2016 19:38:54.229300 mylivesite/components/com_users/controller.php load model registration 03-06-2016 19:38:54.792500 mylivesite/components/com_users/controllers/registration.php before 'attempt to activate the user' 03-06-2016 19:38:54.794100 mylivesite/components/com_users/models/registration.php entry of function activate 03-06-2016 19:38:54.794100 mylivesite/components/com_users/models/registration.php 'admin is activating the account ' 03-06-2016 19:38:55.162100 mylivesite/components/com_users/controllers/registration.php before 'attempt to activate the user' 03-06-2016 19:38:55.163700 mylivesite/components/com_users/models/registration.php entry of function activate

It all just flows through as a result of the verify click.

__extensions com_users params for site that works

{"allowUserRegistration":"1","new_usertype":"2","guest_usergroup":"1","sendpassword":"1","useractivation":"2","mail_to_admin":"1","captcha":"0","frontend_userparams":"0","site_language":"0","change_login_name":"0","reset_count":"10","reset_time":"1","minimum_length":"7","minimum_integers":"1","minimum_symbols":"0","minimum_uppercase":"1","save_history":"1","history_limit":5,"mailSubjectPrefix":"","mailBodySuffix":""}

__extensions com_users params for site that does not work correctly
{"allowUserRegistration":"1","new_usertype":"2","guest_usergroup":"1","sendpassword":"1","useractivation":"2","mail_to_admin":"1","captcha":"0","frontend_userparams":"0","site_language":"0","change_login_name":"0","reset_count":"10","reset_time":"1","minimum_length":"7","minimum_integers":"1","minimum_symbols":"0","minimum_uppercase":"1","save_history":"0","history_limit":5,"mailSubjectPrefix":"","mailBodySuffix":""}

Update 3/7/16

This also happens with a brand new fresh Joomla 3.4.8 install with zero added extensions on the same "live" server.

Going to try and upgrade server to PHP 5.5 and see what happens.

I'm on PHP 5.5 and that makes no difference.
Also tested PHP 5.3: same problem.

@brianteeman: sorry, I did look into the content of that table and the content was not what I expected. But it turns out that the component Improved AJAX Login Register had modified it. I changed it to the default value and disable the component. That made no difference. The author of the component also looked into it and suspected other plugins. But as investigated by terryburg it also occurs on a fresh Joomla install.

I thought maybe something in the server config was driving the process 2X and causing the model code to drop through to the admin approval, but it is even stranger than that. When the code is automatically executed the 2nd time through, it has the admin's token in the URI.

My cowboy code debugging on the live server traces the following through the models registration.php, with the two totally different tokens coming in the URI

03-07-2016 19:39:04.600500 http://mylivesite.com/test/new-user-registration?task=registration.activate&token=a309f919f4fdc10b53b188b8c55e5b61 /mylivesite.com/test/components/com_users/models/registration.php entry of function activate

03-07-2016 19:39:04.600500 /mylivesite.com/test/components/com_users/models/registration.php 'user is verifying their email'

03-07-2016 19:39:05.479200 http://mylivesite.com/test/new-user-registration?task=registration.activate&token=7874b5e01c816e5d6a9a5f3a58baccac /mylivesite.com/test/components/com_users/models/registration.php entry of function activate

03-07-2016 19:39:05.479200 /mylivesite.com/test/components/com_users/models/registration.php 'admin is activating the account '

03-07-2016 19:39:05.954200 http://www.mylivesite.com/test/new-user-registration?task=registration.activate&token=7874b5e01c816e5d6a9a5f3a58baccac /mylivesite.com/test/components/com_users/models/registration.php entry of function activate

Hi terryburg, have you found a solution / workaround?

Not yet.

I have done some more testing with more extensive logging using debug_backtrace, but it show nothing more than I already knew, that the activation entire process is immediately being driven back through all the same programs with the administrator hash in the URL the 2nd time.

When I get some more time I will do more testing.

I know this is a longshot but does your site by any chance have multiple domains/aliases pointed at it? My production site that fails has two. All others that do not fail have just one domain.

No, just one domain.
But (my long shot) www.domain.nl is (in htaccess) rewritten to doman.nl.
I will do a test with the rewriting disabled tonight.

[EDIT] Disabling that rewrite does not help ;-( I also remember that I already tested with a vanilla htaccess, which did not help either.

I've dealed with exact the same problem. But I found the solution in my case.
The hosting company check every link in an email. So the activation link is used for the first time by a spam server. When the admin click on this link, the account is already verified, so it gives an error.

I disallow the IP adresses of the spam servers in my htaccess and now it works fine.

Hopefully this will help soms users!

Regards,
OvGarderen

Hi ovgarderen,
Thanks for your advise. I submitted a ticket at the hosting company and will post the result here.

Thanks very much ovgarderen I thinks that's my problem, too! Or something like it.

I added display of $_SERVER['REMOTE_ADDR'] to my little test logging statements inside com_users/models/registration.php, and lo and behold the first time through "public function activate" there's my IP address, but the second time through it is an IP address registered to the provider. And not the IP address assigned to my website.

I then added a deny statement to my site .htaccess for that IP and all of a sudden things work as advertised - it waited for me to respond to the admin email before activating the user.

Rather surprised this spam filter or whatever it is would allow the emails to go out anyhow without being able to access the site but oh well.

If I was the guys writing Joomla I would never have envisioned this scenario either.

Thanks again, many times. I have about 40 hours unpaid work into investigating this stupid problem and an very glad to have a workaround.

What does not make sense in this scenario however is why the spam server or whatever it is would not have also fired the initial, user verification email. That one went out and required user action just like it was supposed to.

Good to know it make sens to someone ;-)

I think the reason why the users e-mail, with the verification link, does not have the same problems, because the email is still not delivered.
This must be a security rule, otherwise hackers can easely use other emailadresses. I'm not sure about this, but I can imagine this.

If this is true, I think the Joomla developers must also create a secure verification admin link, that will be active after delivering of the admin email. That's the best solution.

@terryburg : could you post the lines you added to com_users/models/registration.php?

I added my debug code to the top of the activate() function. Ended up specifying a special log file because of my circumstances, so you would need to change the directory path (esp. [xxxxxx]) to match your own installation, or else use the ini_get instead statement instead to write to your normal PHP error log. I also had other calls to error_log sprinkled through the program but this one at the top is what showed the calls from different IP addresses with the two different tokens.

So the first several lines of function activate starting at line 34 looks like:

public function activate($token)
{
// this is my debug code
// $errlog = ini_get('error_log');
$errlog = "/home/[xxxxxx]/public_html/test/error_log";
$thisprog = " " . FILE ." ";
$now = DateTime::createFromFormat('U.u', microtime(true));
$rightnow = $now->format("m-d-Y H:i:s.u");
$uri = JUri::getInstance();
$caller = $_SERVER['REMOTE_ADDR'];
error_log($rightnow . " " . $uri . " called by " . $caller . " " . $thisprog . " entry of function activate ".PHP_EOL, 3, $errlog);

// this continues the existing code

$config = JFactory::getConfig();
$userParams = JComponentHelper::getParams('com_users');
$db = $this->getDbo();

etc.

ovgarderen wrote:

"I think the reason why the users e-mail, with the verification link, does not have the same problems, because the email is still not delivered.
This must be a security rule, otherwise hackers can easely use other emailadresses. I'm not sure about this, but I can imagine this."

I'm still not sure. My logging statements show no double call to the link with user token in the model 'registration.php' program (e.g., spam server on the way out, then again user when he gets around to it). The controllers 'registration.php' program does not appear to have code to check much of anything but the system parameters/settings allowing user registration, etc., before it invokes model->activate($token). Nothing about any email having been delivered. The security at that point seems to be the assumption that only the designated user should have the link with the user's verification token.

But then after the user has verified his email address the 2nd email goes out, to the admin, with the admin token, and that magically & immediately drives the Joomla URI from an ISP server (mail server?) using the admin's token. The way I see it, if the ISP's spam checker checks a link in the 2nd email off Joomla addressed to some admin and thus drives the Joomla authorization process, why would it also not check the link in the 1st email to the user and run the initial verification process? That server should not be aware of any Joomla internal state.

Possibilities that come to mind include different headers going out on the two emails and some missing one triggers spam checking, though it does not look like that's the case inside the registration programs, or maybe different handling of the emails at the destinations, where one receiver checks back with the source, and the other does not? In my case the user's email host is Hotmail which is usually one of the harder ones to sneak spam past. From email headers I see the user email went out from one email server and the admin email from another (the one that automatically drove the Joomla admin activation). Neither one has any blocks at Spamhaus. Maybe there's some email server reaction to seeing similar URLs in emails going out close to each other? And maybe the problem might be avoided if Joomla was using SMTP o send email instead of PHPMail? I don't know.

I'm going to raise the issue with the web host ISP and see if they have any clue what might be happening, but based on past performances I would not expect an answer quickly.

I contacted my ISP and described the problem, and the weekend tech acknowledged that yes their mail server will check URLs in outbound emails like that. He's turning to over the server team come Monday, to see what kind of options we have.

Based on the number of reports of reports of problems like this I've seen in various places around the web, I don't think our ISPs are alone in operating like this.

@terryburg I added your code and found that the ISP's firewall indeed jumped in.
Address blocked, SUCCES!
Thanks @terryburg and @ovgarderen !

It appears like that's definitely the issue then, with a mail server scenario the Joomla team did not anticipate.

This week's Internet Hero award to ovgarderen.

If I find out from my ISP what they call this particular configuration option I will post it here. Hopefully someone from Joomla team still following this old dead problem report.

Great it works for you both! And thank you for the award ;-)

My ISP got back to me.

They use something called Barracuda to filter email, inbound and outbound. They whitelisted my site, and now the registration process works properly even without the addition of Deny statements to .htaccess. I guess it is the same thing - Barracuda isn't going to check email from my site.

According to the Barracuda website they have something called Intent Analysis (for inbound and outbound) where "Markers of intent, such as URLs, are extracted and compared against a database maintained by Barracuda Central".

Maybe that is what causes it. Who knows.

https://techlib.barracuda.com/bsf/contentanalysisinbound

One final note on this issue, in the ISP's response to my question of what specifically causes the Spam appliance to run that link:

"Barracuda's Multi-Level Intent filter. It's going to his link to verify that it's not redirecting to a spam website."

They also offered this note from Mailchimp that indicates this is a problem bigger than Joomla:

https://blog.mailchimp.com/spam-filters-automatically-unsubscribing-people/

Lesson for all: Don't send out a link that actually does something when clicked.

But that still doesn't answer the burning question of why the initial email link to the user to verify his email isn't also automatically run. :)

Hi,

We have an issue with registration..on succesfull registration to site, user gets an activation email to activate the account but user is getting activated without mail activation. Somehow account is getting activated. Iam new to joomla please help me to solve this.
These are global configuration settings
Allow User Registration = Yes
New User Account Activation = Self

Hi AiswaryaShivan

I advise you to describe this problem to your ISP.
You can point them to this thread so they can see what the problem is and what caused it (in our case it was the Barracuda Spamfilter of the ISP).
Good luck!