Open daenney opened 6 years ago
Hi, I've not implemented the extensibleObject
behaviour in ldap3. I don't see a valid use for it. Anyway if you think it is helpful in some way I will implement it.
So, in general I loathe extensibleObject
and I don't think support for it is really worth it. However, I do think my initial bug report still stands. If you can create a query with an additional AttrDef and then call .entry_writable
on it you'll be greeted by this error. You can see that behaviour too in my comment on #437 when trying to get operational attributes through the ORM layer. I don't think that should happen. In such cases .entry_writable
should probably log a different, or at least more descriptive, error that informs you you cannot transform a response into a writable object unless it's only constructed out of ObjDefs.
So... this involves
extensibleObject
which I'm aware of is an awful idea. But I have to deal with some legacy so here we are :|.I've defined a user as such:
sshPublicKey
normally comes fromldapPublicKey
from theopenssh-lpk_openldap.schema
. However, since this thing hadextensibleObject
on all user attributes, people helpfully forgot to actually addldapPublicKey
to theobjectClasses
. However, b/c ofextensibleObject
any attr defined by any of the schema's the server has loaded is fair game.I then issued a search and got results back but needed to modify the results for some of the entries. So I loop over
.entries
, and callentry_writable()
. At that point I'm greeted with:Now, I thought I could solve this by changing the
ObjectDef
to includeldapPublicKey
too but then mysearch()
fails to return any results b/c the filter is constructed based on all of the classes in theObjectDef
.Since this thing includes
extensibleObject
I would expect to be able to call.entry_writable()
and not hit this snag because any attribute not defined in any of the other object classes is implicitly a member ofextensibleObject
. Since the connection is opened withget_info=ALL
it should be able to convert and write back this separate attribute properly, just like it managed to read it.To be honest I'm not sure one would want to fix this, b/c
extensibleObject
but it took me by surprise. The easiest way I can see to fix this is to allow to override the filter that is created when passing the object definition toReader
, so that I could there excludeldapPublicKey
. Since it'll then still be in theObjectDef
the conversion to a writable entry should then succeed since that one will include the object class that has the rogue attribute defined. In the meam time I'll run a modify by hand to add that object class to everyone first and then carry on.