WebLoginPE storing auto-generated passwords incorrectly

I was recently alerted that, on our one Evo site, people are signing up with WebloginPE and then getting their password thrown out as incorrect when they try to login - the very same password they received in the confirmation email. Naturally, this isn’t making the client look very good

I went on and signed up for an account myself, and here’s what I found. The system generated the password ’WTp4mjvfzh’ in the confirmation email, but the hash under ’cachepwd’ in the modx_web_users table doesn’t look right. Where normal hashes look something like ’c106b7b9164d81359f6a0f5ad19c4351’, it shows ’1309453124’. Several other user accounts show something similar under ’cachepwd’ - a numeric string of that length instead of a proper hash.

When I change the password for one of these accounts inside the manager, it functions normally and the user can log in using the password I created.

This was working when I originally set it up. The only thing I can think of that has been majorly changed is the version of MODx - I upgraded to 1.0.5 when it came out. I am running the latest version of WLPE, 1.3.1. I can supply snippet calls, chunks, and anything else relevant upon request. This is a real headscratcher for me, and it doesn’t help that I’m now so deep into Revo I can hardly remember how to do anything in Evo (unfortunately upgrading the site to Revo is not an option right now though).

Any help would be greatly appreciated.

One other abnormal behavior I forgot to mention: The Manager title is showing ’SM Page (call)’ on every screen, instead of the site name. Don’t know whether one could have anything to do with the other or not.

Did the hosting do any updates to the site? Certain version changes of PHP and MySQL clients have changed the hash. WebloginPE just uses the PHP md5()function when saving the password, and uses the same md5() function when comparing the submitted password with the database. What



The manager’s save user processor uses the same function

With that oddity in the Manager’s title I would be suspicious of corrupted databases. Try checking and repairing the tables and see what happens.

Thanks for taking time to look at my thread, Susan - I appreciate it

I ran a check on the database; everything showed OK but I decided to be on the safe side and run a repair anyway. That also showed OK on all tables. Just to be on the safe side, I then cleared the cache. The Manager title is still goofed up, but I just registered for a new user account and the auto-generated password worked! Yay!

I still don’t feel 100% confident with the system, but if I can’t actually get it to break again I don’t plan to waste too much time worrying about it.

This didn’t make it to my original post, but I found that the local development copy I was working when the remote one wasn’t. It’s running earlier versions of PHP and MySQL than the production server, but since production is now working, I don’t believe software versions were the cause in this case.

Thanks again for your help!

That business with the title bothers me. Does it say "SM Page (call) - (MODx CMS Manager)", or just "SM Page (call)"?

The title is set in the 1.php frame (from /manager/frames) and the site name part is taken from the main siteCache.idx.php (assets/cache), which in turn was generated from the site_settings table of the database along with a few items generated dynamically from the config.inc.php file.

The cache file can be emptied; it will regenerate itself. I usually open the Configuration, empty the file, then save the Configuration just to make sure. The site_name will come from the first field of the Configuration.

Just wanted to touch base back on this old thread since you, Susan, were so nice as to give me a hand. This issue ended when I migrated the site to Revolution, so it was never properly diagnosed or fixed. Just didn't want to leave this thread hanging.