View Issue Details

IDProjectCategoryView StatusLast Update
0000734SOGoBackend Generalpublic2010-09-20 13:57
Reportermaddog Assigned Towsourdeau 
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Product Version1.3.0 
Target Version1.3.2Fixed in Version1.3.2 
Summary0000734: IDFieldName field not guaranteed to be read if bindFields is used
Description

If bindFields is used for an LDAP source, then nothing in LDAPSource guarantees that the field specified by IDFieldName is requested from the ldap server. In other words, if the IDFieldName is not also specified in the bindFields list, and if it does not happen to be enumerated in the internal "commonSearchFields" member of LDAPSource, it won't get requested. The, the "c_name" attribute of address records will be empty, and all kinds of things will go wrong since "c_name" is presumed to be a unique identifier within a domain.

A sample configuration snippet which triggers this:

   SOGoUserSources = (
       {   CNFieldName = cn;
           IDFieldName = uid;
           UIDFieldName = mail;
           baseDN = "ou=Users,dc=aaa,dc=xxx,dc=com";
           bindFields = (
               mail
           );
           canAuthenticate = YES;
           displayName = "aaa users";
           hostname = localhost;
           id = public;
           isAddressBook = YES;
           port = 389;
           type = ldap;
       }
   );

This config specifies 'uid' as the field containing unique keys. Alas, it is never fetched from the LDAP server.

('uid' is the first component of the DN for an inetOrgPerson.)

I believe the solution is to handle IDField the same way as CNField and UIDField in LDAPSource's _searchAttributes() method.

TagsNo tags attached.

Activities

ludovic

ludovic

2010-09-14 01:15

administrator   ~0001436

Can you try a simple patch?

If so, I think the modification would be in _qualifierForBindFilter:

After:

fields = [bindFields objectEnumerator];
while ((currentField = [fields nextObject]))
[qs appendFormat: @" OR (%@='%@')", currentField, escapedUid];

you could add:

[qs appendFormat: @" OR (%@='%@')", IDField, escapedUid];
ludovic

ludovic

2010-09-14 01:15

administrator   ~0001437

See my comment

maddog

maddog

2010-09-16 21:03

reporter   ~0001473

I don't think that is the right solution: your patch implicitly adds the IDField to the list of bindFields --- whether the user wants that or not. If the user wants to match userid's on IDField, he could just add the IDField to the bindFields list in the configuration file and everything works.

The problem occurs when the IDField is not part of the bindFields list (because it does not supply a valid userid) --- as in the sample config I provided. In this case, the IDField is never fetched.

As I said before, I believe the solution is to handle IDField the same way as CNField and UIDField in LDAPSource's _searchAttributes() method.

I do not have a build environment set up here --- so it's not so simple to try a simple patch. (Plus, feeling a bit leery of messing with what is now a production system.) If it would really help, I could try and set that up, but it would not happen until about a week from now.

wsourdeau

wsourdeau

2010-09-20 13:57

viewer   ~0001482

maddog, you are right. Can you try with the next nightlies?

Fixed in 1acff2251868501e5baba3465e49475362ce1e4b

Issue History

Date Modified Username Field Change
2010-08-07 04:53 maddog New Issue
2010-08-27 01:36 ludovic Target Version => 1.3.2
2010-09-14 01:15 ludovic Note Added: 0001436
2010-09-14 01:15 ludovic Note Added: 0001437
2010-09-14 01:15 ludovic Status new => feedback
2010-09-16 13:06 ludovic Target Version 1.3.2 => 1.3.3
2010-09-16 21:03 maddog Note Added: 0001473
2010-09-20 13:57 wsourdeau Note Added: 0001482
2010-09-20 13:57 wsourdeau Status feedback => resolved
2010-09-20 13:57 wsourdeau Fixed in Version => 1.3.2
2010-09-20 13:57 wsourdeau Resolution open => fixed
2010-09-20 13:57 wsourdeau Assigned To => wsourdeau
2010-09-20 13:57 wsourdeau Target Version 1.3.3 => 1.3.2