Support

Hi, Eoin!

First of all, thank you for making this ticket public. It is an excellent way for me to show how I approach an "impossible" issue like this: reading the code, eliminating possibilities, and taking it from there.

This message you get is the JERROR_NOLOGIN_BLOCKED language string. It is not used in Admin Tools at all. It is, however, used in exactly one place in Joomla: plugins/user/joomla/src/Extension/Joomla.php line 309. It triggers when a user record's block column is set to 1.

Admin Tools does have three features where it can set the user's block to 1 and two where it checks it, but neither applies here:

• SuperUsersList.php:271 is the closest match. It runs $user->block = 1; $user->save(); on a Super User that was added by some unknown route. The save persists the value into the database. You showed block=0, so that's not it.
• TrackFailedLogins.php:126 binds block = 1 into $data, then calls $user->bind($data) and $user->save(). This is the auto-block after repeated failed logins, and it also sets an activation token. Your activation column is empty, so that's not it.
• TemporarySuperUsers.php:191 and DisableObsoleteAdmins.php:375 run a direct database update to set block = 1. You showed block=0, so that's not it.
• DisableObsoleteAdmins.php:181-187 only compares block in onUserBeforeSave data and doesn't modify it. This only applies to backend saves of Super Users, so that's definitely not it.

Moreover, the two features in Admin Tools which implement onUserLogin (therefore could be even remotely implicated in this) are PWAuthOnWebAuthn and NoFrontendSuperUserLogin. Neither has anything to do with block, though. They return a false result to deny a login, resulting in a completely different error message thrown by Joomla.

That is to say, we have determined Admin Tools is not involved here.

For this issue to happen with this database record we'd need a third-party plugin with an onUserLogin handler which sets block=1 on the shared user object instance before Joomla's user plugin runs. I'm not sure if it would work at all, and if it does it would of course depend on plugin ordering. This is very implausible. A user plugin would instead return a false response to deny login, but you'd get a generic login failure instead of the blocked message.

By Occam's razor, this leaves us with exactly one explanation that's simple and explains your result: you're probably looking at the wrong database or database record. Can you do a quick sanity check, reading the site's configuration.php and checking if you're looking at the correct database?

If you're looking at the correct database, read the prefix in the site's configuration.php and check that you're looking at the right table.

If you're really looking at the correct database and table, the only thing left to do is look into the #__extensions table and disable all user plugins except the joomla one.

If that still fails, you can now positively say that you smell a rat; restore from the last known good backup.

When you get blocked, what is the value of the block column of the user record you were logged in as at the time?