Bug#175710: python-ldap modlist patch
Michael Ströder
michael at stroeder.com
Sun Apr 20 19:37:25 CEST 2003
Domenico Andreoli wrote:
>
> On Sun, Apr 20, 2003 at 11:54:52AM +0200, Michael Str?der wrote:
>
>>1. Note that your code does not work with OpenLDAP 2.1.x since this
>>version
>>does stricter error checking on entry data:
>>
>>ldap.NAMING_VIOLATION: {'info': "naming attribute 'uid' is not present in
>>entry", 'desc': 'Naming violation'}
>
> please change the dn to whatever works for you,
I did.
> the problem is not here.
Just for the records: The entry MUST contain uid attribute with recent
OpenLDAP 2.1.x which does stricter checking than e.g. OpenLDAP 2.0.x.
>>2. Strictly spoken you are creating an invalid entry with
>>
>>entry = make_entry(None)
>>
>>The attribute value list of attribute 'description' is simply [ None ]
>>which is filtered in modifyModlist() to []. But it means that the
>>attribute
>>is assumed to be existent in the old_entry. Non-existent attributes should
>>not appear in the entry data at all.
>
> if you state that non-existent attributes should be left out, my standing
> point is, of course, wrong and all this discussion is a non-sense.
Yes, non-existent attributes should be left out.
> then, please note that your code is inconsistent with your affirmation
> because of the last check ("elif old_value and not new_value"). here
> you are explicitly checking whether new_value does not exist and then
> whether the corresponding attribute is non-existent.
I will check that.
>>Note: The diffing in modifyModlist() loops over new_entry.keys(). Whether
>>an attribute is present in old_entry is determined by existence of the
>>attribute type name in the dictionary's keys.
>
> this is the point. None is threated as "null-string" (and then filtered)
> if found in new_value and as "present" if found in old_value. this is
> not a problem unless it is the only item of the list (like in my case).
>
> indeed "if [None]" evaluates to true, while "if []" evaluates to false.
>
> if you filtered also old_value, you would handle perfectly the case of
> non-existent attributes. the choice is yours.
I will check whether it's feasible to filter() old_value. I had some
problems with broken iPlanet DS 5.1 (prior SP1) which returned [] as
attribute value in search results.
Additionally I've learned in the mean-time that some attributes might hold
empty strings (e.g. attributes of DirectoryString syntax). Therefore using
filter(None,valuelist) might be problematic anyway and might be dropped
completely from modifyModList().
=> you're safe if your code leaves out non-existent attributes completely.
For a complete solution modifyModList() would have to look at the schema to
use the appropriate matching rules...
Ciao, Michael.
More information about the python-ldap
mailing list