Menu
▾
▴
python-ldap-dev
|
From: <ca...@fi...> - 2003-04-19 20:43:15
|
hi Michael, the patch you are referring to is already in the python-ldap version i'm using and the problem is right in the "modlist.append((ldap.MOD_DELETE,attrtype,None))". the error i get is from deletion of an inexistent entry. i attached an example to reproduce the bug. cheers cavok On Fri, Apr 04, 2003 at 08:53:06PM +1000, Peter Hawkins wrote: > Well, I'm not sure but I think I already fixed this in a different way: > > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python-ldap/python-ldap/Lib/ldap/modlist.py.diff?r1=1.11&r2=1.12 > > Comment: > "Replace an attribute value by deleting it completely and re-add the whole > attribute value list. This is necessary to make it work with attributes for > which no matching rules are implemented. The caveat is that it might trigger > mor attribute indexing depending on LDAP server implementation." > -----[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 |
|
From: <ca...@fi...> - 2003-04-19 23:54:48
Attachments:
example.py
|
of course i forgot the attachment.. On Sat, Apr 19, 2003 at 10:39:03PM +0200, Domenico Andreoli wrote: > hi Michael, > > the patch you are referring to is already in the python-ldap version i'm > using and the problem is right in the "modlist.append((ldap.MOD_DELETE,attrtype,None))". > the error i get is from deletion of an inexistent entry. > > i attached an example to reproduce the bug. > > cheers > cavok > > On Fri, Apr 04, 2003 at 08:53:06PM +1000, Peter Hawkins wrote: > > Well, I'm not sure but I think I already fixed this in a different way: > > > > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python-ldap/python-ldap/Lib/ldap/modlist.py.diff?r1=1.11&r2=1.12 > > > > Comment: > > "Replace an attribute value by deleting it completely and re-add the whole > > attribute value list. This is necessary to make it work with attributes for > > which no matching rules are implemented. The caveat is that it might trigger > > mor attribute indexing depending on LDAP server implementation." > > -----[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 |
|
From: <mi...@st...> - 2003-04-20 09:55:01
|
Domenico Andreoli wrote:
> hi Michael,
>
> the patch you are referring to is already in the python-ldap version i'm
> using and the problem is right in the "modlist.append((ldap.MOD_DELETE,attrtype,None))".
> the error i get is from deletion of an inexistent entry.
>
> i attached an example to reproduce the bug.
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'}
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.
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.
Ciao, Michael.
|
|
From: <ca...@fi...> - 2003-04-20 16:17:25
|
hi Michael,
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, the problem is not here.
> 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.
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.
> 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.
> Ciao, Michael.
>
ciao :)
domenico
-----[ Domenico Andreoli, aka cavok
--[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc
---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
|
|
From: <mi...@st...> - 2003-04-20 17:37:37
|
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.
|
|
From: <mi...@st...> - 2003-04-20 18:05:38
|
Michael Str=F6der wrote: > I will check whether it's feasible to filter() old_value. I had some=20 > problems with broken iPlanet DS 5.1 (prior SP1) which returned [] as=20 > attribute value in search results. >=20 > Additionally I've learned in the mean-time that some attributes might=20 > hold empty strings (e.g. attributes of DirectoryString syntax).=20 > Therefore using filter(None,valuelist) might be problematic anyway and = > might be dropped completely from modifyModList(). > =3D> you're safe if your code leaves out non-existent attributes comple= tely. I've checked in a new version with the following change: -------------------------- snip -------------------------- ldap.modlist: * modifyModlist(): Only None is filtered from attribute value lists, '' is preserved as valid attribute value. But filtering applies to old_value and new_value now. -------------------------- snip -------------------------- Please test! Ciao, Michael. |
|
From: <ca...@fi...> - 2003-04-23 11:40:32
|
On Sun, Apr 20, 2003 at 08:05:32PM +0200, Michael Str?der wrote: > > I've checked in a new version with the following change: > where did you checked the stuff in? i'm looking at the sourceforge CVS repository but i still do not see any change :( -----[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 |
|
From: <mi...@st...> - 2003-04-23 13:48:22
|
Domenico Andreoli wrote: > On Sun, Apr 20, 2003 at 08:05:32PM +0200, Michael Str?der wrote: > >>I've checked in a new version with the following change: >> > > where did you checked the stuff in? i'm looking at the sourceforge CVS > repository but i still do not see any change :( Aaargh! Sorry. Done now. Ciao, Michael. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X