Description
dn: cn=testGroup,ou=groups,dc=example,dc=edu
|
objectClass: groupOfNames
|
objectClass: top
|
cn: testGroup
|
member: employeeId=940002073,ou=people,dc=example,dc=edu
|
member: employeeId=940002080,ou=people,dc=example,dc=edu
|
member: employeeId=940002084,ou=people,dc=example,dc=edu
|
member: cn=otherGroup,ou=groups,dc=example,dc=edu
|
When used with loaderLdapElUtils.convertDnToSpecificValue(subjectId), the loader will parse every row indiscriminately, including the row which is not a person. At minimum there will be unresolvable subjects, but at worst the non-person member will accidentally have the same id as a real person, and that person will incorrectly be loaded.
There should be some way to indicate to skip rows. The existing jexl converter property would be a good place for it.
Experiment 1:
${ subjectId.startsWith('employeeId=') ? loaderLdapElUtils.convertDnToSpecificValue(subjectId) : null}
|
This calculates a subjectId of "null" in 2.6.19, and since there is no subject with this id, it is an unresolvable subject. Other rows do load. There is a warning in the daemon log for the bad row, but the job log is success, and nothing is in the job log about any bad rows.
Experiment 2:
${ subjectId.startsWith('employeeId=') ? loaderLdapElUtils.convertDnToSpecificValue(subjectId) : ""}
|
Runtime exception: "Result has a null subject_id, please correct the query (maybe just filter where subject_id is not null)". No rows loaded, and the job ends in error state.
Experiment 3:
LDAP_GROUPS_FROM_ATTRIBUTES, setting Attribute filter expression
Result: Doesn't work – the filter expression is for the group attribute, not the subjects.