Edit user erases dn

[Jack Zielke]

We had a problem where some users were not able to log in. This was tracked down to just the users that had a group assigned to them. Looking in the database the dn field was blank for these users and only for these users.

model/user/user.php line 417

      $query = $this->db->query("UPDATE " . TABLE_USER . " SET username=?, realname=?, domain=?, dn=?, isadmin=? WHERE uid=?", array($user['username'], $user['realname'], $user['domain'], @$user['dn'], $user['isadmin'], (int)$user['uid']));

Editing a user without changing anything will erase the dn. var_dump shows that $user does not have 'dn' so it is set to null on update. Removing dn from the update command solves this problem.

      $query = $this->db->query("UPDATE " . TABLE_USER . " SET username=?, realname=?, domain=?, isadmin=? WHERE uid=?", array($user['username'], $user['realname'], $user['domain'], $user['isadmin'], (int)$user['uid']));

[Janos SUTO]

What version do you use? Can you download the master branch, and try with its gui? Just take the webui dir, no need to upgrade the binaries or the database schema for the test.

[Jack Zielke]

piler 0.1.25-master-branch, build 846

I will grab the latest and see what happens.

[Jack Zielke]

Same problem, I just commented out the update query and replaced it with LOGGER('dn test: ' . @$user['dn']); When that was blank I replaced it with var_dump($user); $user contains: uid, email, username, realname, domain, s_piler_domain, domains, s_piler_group, group, s_piler_folder, folder, password, password2, isadmin

[Janos SUTO]

OK, thanks for trying. However please tell me a bit more about your setup. How do you authenticate your users?

[Jack Zielke]

ldap_sync runs once per day.

[Janos SUTO]

I see. In the recent versions of the gui the idea is to keep only administrative users (eg. admins and auditors) in the local database, and let the gui authenticate the rest ie. regular users against an LDAP database.

I can fix the sql query to solve issue (thanks for nailing it down), however if your environment allows it, then I believe that authenticating against an LDAP database is a more viable solution.

I know that I claimed that for groups you needed local users in the database, however recent version no longer require it. If you have some time, then I'd like you to try it.

[Jack Zielke]

I will give that a go in a bit. I changed edit.tpl to var_dump $user on load and 'dn' is populated. It looks like ENABLE_LDAP_IMPORT_FEATURE has to be set to 1 or dn will not end up in the template. I set that to 1 in my site config file. That caused dn to be part of the form and then original query works fine.

[Janos SUTO]

You are right, ENABLE_LDAP_IMPORT_FEATURE=1 is the fix.