6.0.0-git
2019-03-23

[#1317] Inconsistencies between datatree and LDAP when working on a Kolab backend
Summary Inconsistencies between datatree and LDAP when working on a Kolab backend
Queue Kolab
Type Bug
State Resolved
Priority 2. Medium
Owners stuart (at)
Requester a.gungl (at) gmx (dot) de
Created 2005-02-07 (5157 days ago)
Due
Updated 2006-11-20 (4506 days ago)
Assigned 2005-11-22 (4869 days ago)
Resolved 2006-11-20 (4506 days ago)
Milestone
Patch No

History
2006-11-20 14:21:25 Jan Schneider Comment #8
State ⇒ Resolved
Reply to this comment
Fixed with patches from #4662.
2006-02-08 23:39:38 Jan Schneider Comment #7 Reply to this comment
OK, we need a _username_hook_frombackend() then, that is enabled by 
default with Kolab, that makes sure that we always use the user's mail 
attribute internally.

I added an example hook to hooks.php.dist, but it is untested, and I 
have no idea if it does what it is supposed to do. Please test.
2006-02-08 16:28:20 tokoe (at) kde (dot) org Comment #6 Reply to this comment
Hi,



with regard to the upcoming kolab 2.1 and multidomain support it would 
be better to use the email address for internal queries.



Ciao,

Tobias
2005-12-27 12:01:26 Jan Schneider Version ⇒
Queue ⇒ Kolab
 
2005-12-05 11:44:06 vovan (at) planet (dot) nl Comment #5 Reply to this comment
Understood. So we should always use either uid or mail internally, no
matter which one the user uses for login. Which one makes more sense,
especially looking ahead to multidomain support in Kolab 2.1? How
will user names look like then?
Unfortunatelly I don't have development version of Kolab installed, so 
can't say anything about that at the moment. Maybe later I'll have 
some time  to install it.

Hopefully somebody can post come comments....
2005-12-05 10:48:39 Jan Schneider Comment #4 Reply to this comment
Understood. So we should always use either uid or mail internally, no 
matter which one the user uses for login. Which one makes more sense, 
especially looking ahead to multidomain support in Kolab 2.1? How will 
user names look like then?
2005-12-05 09:16:03 vovan (at) planet (dot) nl Comment #3 Reply to this comment
Can you point to that LDAP ticket? And why do you think we should use
"mail" as the internal user name instead of "uid"? Does this have any
advantages regarding to Kolab?
I think there is some kind on missunderstanding... Firstly, I have the 
same issue as described in the ticket (tested with both the latest 
Horde-stable and Horde-cvs). The problem appears only when "uid" isn't 
the same as "mail". So in this case Horde with Kolab backend works 
correctly _only_ if you login with your mail address, but not with 
uid! Of course, I don't think we should use mail instead of uid as 
internal user name. Would be the best if we can use both of them 
without problems.
2005-11-22 23:34:36 Jan Schneider Comment #2
State ⇒ Feedback
Priority ⇒ 2. Medium
Reply to this comment
Can you point to that LDAP ticket? And why do you think we should use 
"mail" as the internal user name instead of "uid"? Does this have any 
advantages regarding to Kolab?
2005-02-07 14:49:39 Chuck Hagenbuch Summary ⇒ Inconsistencies between datatree and LDAP when working on a Kolab backend
 
2005-02-07 13:42:47 Jan Schneider Assigned to stuart
State ⇒ Assigned
 
2005-02-07 13:36:20 a (dot) gungl (at) gmx (dot) de Comment #1
Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 3. High
Summary ⇒ Inconsitences between datatree and LDAP when working on a Kolab backend
Queue ⇒ Horde Framework Packages
Reply to this comment
Horde allows to login via "mail" or "uid" attribute value in LDAP. 
This works fine.However, the queries in the datatree are done based on 
the login value of the user. If uid=mail, that doesn't matter, but 
having uid=name and mail=name@domain might let the datatree double the 
data for the same user. In my case there is the problemthat data for 
the user can't be retrieved when he logs in via uid, while everything 
works fine when using the mail value.

There has been a related ticket some days ago, which was about reading 
and storing in LDAP. This _is_ solved. This ticket is about using the 
same approach in the datatree, i.e. use the value for the primary LDAP 
search attribute (Prefs/Prefs/kolab.php sets $params['uid'] = 
array('mail', 'uid'); to access the Kolab LDAP server) for the 
datatree access (in this example the value of "mail" and not of "uid").

Saved Queries