View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000734 | SOGo | Backend General | public | 2010-08-07 04:53 | 2010-09-20 13:57 |
Reporter | maddog | Assigned To | |||
Priority | normal | Severity | minor | Reproducibility | always |
Status | resolved | Resolution | fixed | ||
Product Version | 1.3.0 | ||||
Target Version | 1.3.2 | Fixed in Version | 1.3.2 | ||
Summary | 0000734: 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:
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. | ||||
Tags | No tags attached. | ||||
Can you try a simple patch? If so, I think the modification would be in _qualifierForBindFilter: After: fields = [bindFields objectEnumerator]; you could add: |
|
See my comment |
|
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. |
|
maddog, you are right. Can you try with the next nightlies? Fixed in 1acff2251868501e5baba3465e49475362ce1e4b |
|
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 |
|
Note Added: 0001482 | |
2010-09-20 13:57 |
|
Status | feedback => resolved |
2010-09-20 13:57 |
|
Fixed in Version | => 1.3.2 |
2010-09-20 13:57 |
|
Resolution | open => fixed |
2010-09-20 13:57 |
|
Assigned To | => wsourdeau |
2010-09-20 13:57 |
|
Target Version | 1.3.3 => 1.3.2 |