MantisBT - v3.0 Release
View Issue Details
0001236v3.0 Release[All Projects] Generalpublic2012-12-30 10:182013-08-28 11:17
Reporteropto 
Assigned Tocaseydk 
PrioritynormalSeveritycrashReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
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

Notes
(0002778)
caseydk   
2013-01-30 23:37   
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..
(0002780)
lukeD   
2013-02-01 00:34   
(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

(0002781)
jonhalle   
2013-02-01 04:59   
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();
            $tmpUser->load($this->user_id);

            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;
        }
(0002782)
caseydk   
2013-02-01 11:21   
Very good catch. I'm not sure why I didn't catch it earlier..

Regardless, you were completely right, so I've patched core:
https://github.com/web2project/web2project/pull/182

Issue History
2012-12-30 10:18optoNew Issue
2013-01-30 23:37caseydkNote Added: 0002778
2013-01-30 23:37caseydkStatusnew => feedback
2013-02-01 00:34lukeDNote Added: 0002780
2013-02-01 01:00lukeDNote Edited: 0002780
2013-02-01 04:59jonhalleNote Added: 0002781
2013-02-01 11:21caseydkNote Added: 0002782
2013-02-01 11:21caseydkStatusfeedback => resolved
2013-02-01 11:21caseydkResolutionopen => fixed
2013-02-01 11:21caseydkAssigned To => caseydk
2013-08-28 11:14caseydkFixed in Version => 3.0.0
2013-08-28 11:17caseydkStatusresolved => closed