0015712: RealNames not displayed correctly while using LDAP auth and 'use_ldap_realname' options - MantisBT - Signup temporarily disabled due to spam

ID	Project	Category	View Status	Date Submitted	Last Update

0015712	mantisbt	other	public	2013-04-04 03:56	2022-06-11 10:54

Reporter	alxshr	Assigned To
Priority	normal	Severity	minor	Reproducibility	always
Status	feedback	Resolution	open
Product Version	1.2.13

Summary	0015712: RealNames not displayed correctly while using LDAP auth and 'use_ldap_realname' options
Description	When using LDAP auth (I am using AD server) and setting the options 'use_ldap_realname' to true, function user_get_name() in core/user_api.php always returns the local real name and not the one coming from the LDAP.
Tags	No tags attached.

alxshr 2013-04-04 03:59 reporter ~0036032	Fix suggested in pull request. https://github.com/mantisbt/mantisbt/pull/78

dregad 2013-04-04 04:31 developer ~0036033	The reason it's done this way (i.e. pulling the info from DB), is that the user table currently acts as a "cache" for LDAP information, which is stored/updated after each successful login by the user [1]. I guess the idea behind this was to improve performance by reducing the amount of LDAP traffic, as loading a single MantisBT page can trigger hundreds of LDAP queries. I'll grant you that this is not ideal as there can be a discrepancy between the master data (LDAP directory) and the Mantis DB, especially for users who don't login frequently. However I don't think your fix should be applied as-is because it only fixes part of the problem, i.e. what about other LDAP-maintained fields (password, e-mail) introduces a potential performance issue (see my above comment) [1] https://github.com/mantisbt/mantisbt/blob/master-1.2.x/core/ldap_api.php#L397

alxshr 2013-04-04 04:40 reporter ~0036035	In my case the users almost do not login to the system, as we are using EmailReporting with it... So, In most of the cases the local records are not in sync with the directory. I agree about the potential performance issue, however it has no relation to other LDAP related fields as I refer to configuration option 'use_ldap_realname'. As I see it, is that when one sets this option to true he is well aware of the impact it may cause on the system, and he knows that it refers ONLY to real name field.

alxshr 2013-04-04 04:43 reporter ~0036036	Maybe it can be useful to update user's details from LDAP on issue submission, thus if one submits an issue, his details will be synced.

dregad 2013-04-04 07:54 developer ~0036041	That could be an idea actually. The only catch is to find the most relevant/appropriate event to trigger the update of Mantis user table with LDAP info. Ideas: when issue is submitted or, probably better, modified: update Mantis user table with LDAP information for all related user accounts (e.g. the reporter, handler, monitors and note adders) user "update" activity: update that user's account For implementation, 1. can probably be hooked into bug_api, and 2. into history_api. These would effectively improve the situation (i.e. reduce the risk of displaying outdated user info), but I don't think any one of them is perfect. An alternative could be to build a back-end script that can be scheduled to run, e.g. on a daily basis, to mass-update the user profiles's info from LDAP. Thoughts?

vboctor 2013-05-01 03:08 manager ~0036750	Even if we do the suggested hooks, there are still users on issues that have already been submitted that may become stale. This is in addition to the synchronous performance degradation due to these extra LDAP updates that typically yield no added value. Hence, I would prefer the idea of cronjob that goes through all users into MantisBT and refreshes their info from LDAP. Why doesn't EmailReporting plugin also refresh from LDAP similar to login workflow?