Repository navigation
Avoid unconditional loginName2UserName in UserManager::getUserObject #7445
Description
Apparently it was once introduced to fix a bug when resetting the password (typical for local users). However, this is attempted in every call for the user object, and in case of LDAP leading to an additional lookup using the internally used name to the LDAP server.
Proposed solution:
- write a test to resest password with different case loginname
2a. throw the preLoginNameUsedAsUserName Hook in the Controller. Ideally move also to dispatcher
2b. Since it is use just an optional user backend method, just establish an API method in the manager and call it when necessary, to avoid hooks. Other usages (I am aware about federate sharing) should be revisited, too.
Perhaps better for 14.
Activity
blizzz commentedon Dec 19, 2017
I also suspect this to cause file:scan issues (symptom:
initMountPoints() called with wrong user casing. This could be a bug.) when you have different LDAP users that discriminate against each other by casing only ("dfoobar" and "DFoobar" for instance).blizzz commentedon Dec 19, 2017
While I could not reproduce the error message above, in this scenario the file scan background job will never scan DFoobars files.
I could not adapt it to local users, since it is case insensitive and does not allow usernames with just different casings. A hack for LDAP is easy, just opens the door for other, different side effects.
Anyway, this turns it into a bug.