[Tickets #2940] NEW: LDAP entry failes when cn contains comma

[bugs@bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/?id=2940
-----------------------------------------------------------------------
 Ticket             | 2940
 Created By         | horde at dbservice.com
 Summary            | LDAP entry failes when cn contains comma
 Queue              | Turba
 Version            | HEAD
 State              | Unconfirmed
 Priority           | 1. Low
 Type               | Bug
 Owners             | 
+New Attachment     | ldap.log
-----------------------------------------------------------------------


horde at dbservice.com (2005-11-08 16:10) wrote:

Turba's common name is in LDAP addressbook maped to the attribute cn. This
attribute is in LDAP schema inetOrgPerson classified as required, rdn, i.e
something like 'relative primary key'.  In sources.php the following mapping
between turba and ldap attributes is defined (snippet)

       '__key' => 'dn',
        'name' => 'cn',
        'firstname' => 'givenName',
        'lastname' => 'sn'

When cn contains comma, example common name = 'Doe, John' (that is done when
SyncML inserts  new entry),  LDAP server converts this common name into the
string 'cn=Doe\2C John'.  When later any other attribute of this record is
modified, save complains about duplicate record - error 68: Already exists
(see the attached ldap.log). IMO Horde compares the string 'Doe\2C John'
with 'Doe, John'. Because they differs, Horde evaluates this as primary key
change and tries to modify this key. The similar situation happens when
common name contains more then one space between words. This multiple spaces
are striped out by LDAP server before dn is saved.