Anonymous Login
2022-09-26 14:38 PDT

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0001236v3.0 Release[All Projects] Generalpublic2013-08-28 11:17
Assigned Tocaseydk 
Product Version 
Target VersionFixed in Version3.0.0 
Summary0001236: changing user role makes password inoperable
Descriptionmy user was user type default user, role administrator.
I noticed that and changed user role to administrator.
Now, he cannot log in any longer
TagsNo tags attached.
Attached Files




caseydk (administrator)

You changed the role or the type to Administrator? Once again.. no dice.

I'm using Firefox on Ubuntu in case that's the difference..


lukeD (reporter)

Last edited: 2013-02-01 01:00

I can confirm this bug.
Basically, changing a user type (not role) also changes that users password.
But it's not only the user type. The password change also happens when you change the users name, company, etc.

I checked the users table in the db and after changing user info the system always writes "d41d8cd98f00b204e9800998ecf8427e" in the password field, independent of what the password was before or which property was edited.

The admin can change a users password and it gets save properly, but any subsequent change to user info causes the password to be set to "d41d8cd98f00b204e9800998ecf8427e".

So far I could tracking down to "function hook_preUpdate()" in users.class.php. If you comment out the line "$this->user_password = $this->authenticator->hashPassword($this->user_password);" the password changes don't happen, but explicitly setting the password doesn't work either.

Anyways... hope this helps.

PHP 5.3.6-13ubuntu3.9 with Suhosin-Patch (cli) (built: Sep 12 2012 19:00:27)
mysql Ver 14.14 Distrib 5.1.67, for debian-linux-gnu (x86_64) using readline 6.2


jonhalle (reporter)

2 observations, hope they help in some way:

1. d41d8cd98f00b204e9800998ecf8427e is the MD5 hash of an empty string. therefore that user_password is not getting passed across nicely

2. There seems to be some inconsistency in which code is getting called for update and which for addition.

 protected function hook_preUpdate() {
        $this->perm_func = 'addLogin';

Seems strange - almost looks like the logic is the wrong way around , ie update checks are getting called for addition and vice versa. Have not tested this as don't have 3.0 up and running but seems the opposite way around to the code that does the same thing in 2.4:

      if ($this->user_id && $perms->checkModuleItem('users', 'edit', $this->user_id)) {
            $perm_func = 'updateLogin';
            $tmpUser = new CUser();

            if ('' == trim($this->user_password)) {
                $this->user_password = $tmpUser->user_password;
            } elseif ($tmpUser->user_password != md5($this->user_password)) {
                $this->user_password = md5($this->user_password);
            } else {
                $this->user_password = $tmpUser->user_password;

            if (($msg = parent::store())) {
                $this->_error = $msg;
                return false;
            $stored = true;

        if (0 == $this->user_id && $perms->checkModuleItem('users', 'add')) {
            $perm_func = 'addLogin';
            $this->user_password = md5($this->user_password);

            if (($msg = parent::store())) {
                $this->_error = $msg;
                return false;

            $stored = true;


caseydk (administrator)

Very good catch. I'm not sure why I didn't catch it earlier..

Regardless, you were completely right, so I've patched core:

-Issue History
Date Modified Username Field Change
2012-12-30 10:18 opto New Issue
2013-01-30 23:37 caseydk Note Added: 0002778
2013-01-30 23:37 caseydk Status new => feedback
2013-02-01 00:34 lukeD Note Added: 0002780
2013-02-01 01:00 lukeD Note Edited: 0002780
2013-02-01 04:59 jonhalle Note Added: 0002781
2013-02-01 11:21 caseydk Note Added: 0002782
2013-02-01 11:21 caseydk Status feedback => resolved
2013-02-01 11:21 caseydk Resolution open => fixed
2013-02-01 11:21 caseydk Assigned To => caseydk
2013-08-28 11:14 caseydk Fixed in Version => 3.0.0
2013-08-28 11:17 caseydk Status resolved => closed
+Issue History