[SOLVED] Users Cannot Login

Here we go again. I have this gut feeling this is due to some Auto Action issue, but when these things start out of the blue I never know where to look first. No errors reported in the system error_log file related to CB over the past 24 hours.

All of a sudden, about 3 hours ago, users started complaining that they can't login. I have not changed any site configuration parameters in weeks. I have, however, been working on Auto Actions, but only those triggered off the onAfterUserConfirm event. I have unpublished the last one I added that triggers off this event (which was meant to forcibly set block=0 in the #__users table). That made no difference.

I guess it's fortunate that my wife's account is one that cannot login, though once she logs out she will not be happy.

I do not see a #__session table record for my wife, yet she is logged in. What does that tell me? Also, when I try logging in on a different machine (it fails as I mentioned), I don't see a new session for her (wouldn't expect to, but why no session record for her being logged in now)? I also see quite a few users with multiple session records, and many session records with no userid (guests).

It makes me wonder if suddenly the site is no longer able to insert session records. Does that sound plausible? What would cause this? This site has me digging holes in my scalp (because I already pulled all my hair out). Anyone? Bueller?

Help!

Edit: Update on this. I can set the password of a user who has been mysteriously "locked out" using the Joomla User Manager and then they are able to login again. So whatever this is, it appears to be corrupting passwords.

Check the _users database table and review a user that can't login. Check their password column as maybe that's being altered somehow. For the accounts that can't login were they all updated recently? As in profile updates or auto action triggering a user store on their account? Do you've any 3rd party Joomla user plugins within Extensions > Plugins? Those can all act on and alter Joomla user storage behavior. Only "User - Joomla!" should be published ideally.

I can try taking a look if you PM backend super user login credentials, but without a test account to reliably reproduce the issue I'll mostly just be reviewing your configuration.

(which was meant to forcibly set block=0 in the #__users table)

You really need to find out what is doing this rather than trying to bandaid the issue with CB Auto Actions.

I have ascertained that passwords are getting corrupted when a user tries to save their profile or reset their password via the "Forgot Login?" method. Either way, once they do that, their password is NOT going to work (anymore). I did this by simply setting my password using the Joomla User Manager, going to the #__users table and copying my encrypted password into a text file, then editing my profile using the CB User Manager (in the back end...it doesn't matter; they both do the same thing) to set my password to the very same value, then going into the #__users table again and sure enough, the password was different. Sounds like an Auto Action issue, right?

So I unpublished all AA's that trigger off profile save. Some trigger onBeforeUserUpdate|onBeforeUpdateUser and some trigger After. After doing that I was able to save my profile and change my password with the CB User Manager and log back in. Then I published each of the AA's one by one until there was one left, all along the way confirming my profile changes were saving and I could log out and back into the site back end. So it has to be that AA, right? For fear of getting caught in that situation again, I did not republish that one. Instead, I am hoping you can examine that Code AA's PHP code and tell me if you see anything that could be a problem. I don't see it, but you know how that is after you've stared at something for a few days.

This AA is triggered off onBeforeUserUpdate or onBeforeUpdateUser. There are quite a few conditions to meet for this to even get executed, but I did not think those were relevant here (though the fact is requires an address change makes me wonder why the effect was so rampant).

The file get-latlon.php has several functions that do different things related to Google Maps API. That entire set of functions has been thoroughly tested and is in use all over the site. So please do not focus on that. But I will explain what's going on here.

I have never been sure if CB AA's come equipped with a database object (e.g., $db), so I create $mydb here. I need it to lookup the timezone for the user's zipcode (cb_zip). It is not used to update anything. I send all the parts of the user's address into the getlatlon function, which does the Google API query and returns the pieces of information I need in an array, $coord. It's important that the zipcode be right or looking it up in my national zipcodes table won't work. So I default to using what Google gives me (postal_code), but if that's NULL (and that does happen), I have no choice but to resort to using the user-entered cb_zip.

Since this is an AA triggered off onBeforeUserUpdate, I can use the $user object to update the CB fields you see there using the values returned from getlatlon. If the result of getlatlon is that Google couldn't geocode the address, the status will not be OK, in which case I put that status into the cb_lon field so I can see what the error was (this almost never happens).

For whatever reason, publishing this AA keeps the profile save from completing AND WORSE YET, IT CORRUPTS THE USER'S PASSWORD. Yep, it does. All I have to do is republish this and I can reproduce it in a heartbeat (OK, I haven't tried it but it happened every time before I unpublished all those AAs together and this is the only one left unpublished).

I would love to get some feedback on this, to get to the bottom of it. When I tested this code, I did not have the luxury of CB's variable substitution. The code works fine when I put hard-coded strings in. So something is going on with substitution. And no, that included file get-latlon.php does not use any substitution. It's used all over the site, not just in CB AA's.

This really hurts my head.

Bruce

For whatever reason, publishing this AA keeps the profile save from completing AND WORSE YET, IT CORRUPTS THE USER'S PASSWORD. Yep, it does. All I have to do is republish this and I can reproduce it in a heartbeat (OK, I haven't tried it but it happened every time before I unpublished all those AAs together and this is the only one left unpublished).

That probably means your code is erroring and completely interrupting the save process to begin with. It's probably the below.


You forgot the quotes around the substitution. You need to always treat substitutions as strings. Try changing it to the below and see if that resolves your issue.


Enable debug mode and maximum error reporting in Joomla global configuration. Next enable Debug under Parameters of your auto action. It should then display any errors it catches in Joomlas message queue (usually displayed at the top of the page).

Nope. Same exact behavior. Are single quotes OK there? I know CB is sensitive about double quotes in other substitutions.

Single quotes are fine there as it's just PHP. There's nothing more I can suggest as it's clearly a problem with the custom code somewhere. Have you tried enabling debug mode and maximum error reporting in Joomla global configuration followed by debug mode in the auto action to see if any errors output when the auto action would trigger?