You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a class with annotation @entry(objectClasses = {"top"})
but several ldap nodes have only the objectClass=inetOrgPerson which is correct because inetOrgPerson inherits from top. Spring-ldap submits a query
(&(objectClass=top)(uid=...))
to the server and the server responds with all nodes because it knows about the inheritance. For nodes with objectClass=inetOrgPerson only the server sends only this objectClass back to the client without the inherited objectClass top.
But there is a check in org.springframework.ldap.odm.core.impl.DefaultObjectDirectoryMapper#mapFromLdapDataEntry
if(!collectionContainsAll(objectClassesFromJndi, metaData.getObjectClasses()))
that throws away all results that do not have an explicit objectClass=top in the server's response.
IMHO, spring-ldap should trust the ldap server and do not throw away such results. But at least there should be an option for disabling/enabling this extra check.
The text was updated successfully, but these errors were encountered:
Torsten Werner (Migrated from LDAP-303) said:
I have a class with annotation
@entry(objectClasses = {"top"})
but several ldap nodes have only the objectClass=inetOrgPerson which is correct because inetOrgPerson inherits from top. Spring-ldap submits a query
(&(objectClass=top)(uid=...))
to the server and the server responds with all nodes because it knows about the inheritance. For nodes with objectClass=inetOrgPerson only the server sends only this objectClass back to the client without the inherited objectClass top.
But there is a check in org.springframework.ldap.odm.core.impl.DefaultObjectDirectoryMapper#mapFromLdapDataEntry
if(!collectionContainsAll(objectClassesFromJndi, metaData.getObjectClasses()))
that throws away all results that do not have an explicit objectClass=top in the server's response.
IMHO, spring-ldap should trust the ldap server and do not throw away such results. But at least there should be an option for disabling/enabling this extra check.
The text was updated successfully, but these errors were encountered: