cannatag / ldap3

a strictly RFC 4510 conforming LDAP V3 pure Python client. The same codebase works with Python 2. Python 3, PyPy and PyPy3
Other
875 stars 271 forks source link

Non-automatic recognition of auxiliary objectClasses #1065

Open jasongabler opened 1 year ago

jasongabler commented 1 year ago

My organization has a custom structural objectClass of ucsfEduPerson. It's a subclass of inetOrgPerson. It incorporates the auxiliary objectClass of eduPerson by referring to the eduPersonAffiliation attribute. If I do not specify the auxiliary class when creating an ObjectDef for ucsfEduPerson, subsequent search operations on that structural objectClass will fail when specifically trying to retrieve eduPersonAffiliation or ldap3.ALL_ATTRIBUTES. It seems this is because Ldap3 doesn't know what to do with the eduPersonAffiliation attribute returned by my LDAP server as it is not aware of the auxiliary association. It behaves as though the LDAP server is in error, having returned an attribute that is not in the structural objectClass' schema.

I did get this to work, of course, by specifying the auxiliary objectClass when creating the ObjectDef. But, I've never had to provide that sort of additional instruction with any other LDAP library. So I was surprised. I would surmise that the other LDAP libraries I've used see the reference to an auxiliary objectClass when retrieving the structural objectClass defitniion and make an additional call to retrieve the auxiliary definition, or at least enough to incorporate the desired attributes as viable members of the structural objectClass.

What is the benefit of Ldap3 not taking this extra step? Obviously, it's not a deal breaker to have to put in a few dozen more characters of code. But, from my experience, it would seem to be more like an oversight. Now that I've spent 3 hours figuring out what was going on, I'll never have this problem again. And, thankfully, I've learned something along the way. But, shouldn't Ldap3 also do this extra step? The real question I have, why doesn't it?

cannatag commented 1 year ago

Hi Jason, when you use the Abstraction Layer you are using an additional framework upon the LDAP3 protocol. This layer “abstracts” the data from the protocol for the standard ldap classes, but for custom classes you must provide the relevant schema, as you would do with an ORM in a DB. If you use the ldap3 library without the abstraction layer it behaves like all the other ldap client libraries and you don’t need to provide any additional information to access the data.Bye,GiovanniIl giorno 1 nov 2022, alle ore 01:44, Jason Gabler @.***> ha scritto: My organization has a custom structural objectClass of ucsfEduPerson. It's a subclass of inetOrgPerson. It incorporates the auxiliary objectClass of eduPerson by referring to the eduPersonAffiliation attribute. If I do not specify the auxiliary class when creating an ObjectDef for ucsfEduPerson, subsequent search operations on that structural objectClass will fail when specifically trying to retrieve eduPersonAffiliation or ldap3.ALL_ATTRIBUTES. It seems this is because Ldap3 doesn't know what to do with the eduPersonAffiliation attribute returned by my LDAP server as it is not aware of the auxiliary association. It behaves as though the LDAP server is in error, having returned an attribute that is not in the structural objectClass' schema. I did get this to work, of course, by specifying the auxiliary objectClass when creating the ObjectDef. But, I've never had to provide that sort of additional instruction with any other LDAP library. So I was surprised. I would surmise that the other LDAP libraries I've used see the reference to an auxiliary objectClass when retrieving the structural objectClass defitniion and make an additional call to retrieve the auxiliary definition, or at least enough to incorporate the desired attributes as viable members of the structural objectClass. What is the benefit of Ldap3 not taking this extra step? Obviously, it's not a deal breaker to have to put in a few dozen more characters of code. But, from my experience, it would seem to be more like an oversight. Now that I've spent 3 hours figuring out what was going on, I'll never have this problem again. And, thankfully, I've learned something along the way. But, shouldn't Ldap3 also do this extra step? The real question I have, why doesn't it?

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>