Re: Bug#175710: python-ldap modlist patch

[<mi...@st...>]

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.