Open jasongabler opened 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: @.***>
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?