From: <mi...@st...> - 2004-05-05 17:31:55
|
pn...@ma... wrote: > > I then tried to compile it from the tar.gz file. However, that complains > of not finding a file that is suppose to be located within the directory > of the extracted python-ldap directory. Did you forget to include > Lib/ldap.py and schema.py in the Lib directory? See item 6. on http://python-ldap.sourceforge.net/faq.shtml > what is the long term support of LDAP within Python? See item 1. on http://python-ldap.sourceforge.net/faq.shtml You're welcome to join the mailing list (Cc:-ed - rather low-traffic). Ciao, Michael. |
From: Timur I. <Tim...@oi...> - 2006-04-12 12:29:46
Attachments:
ldap_passwd.diff
|
Michael, Thanks for answering! On Fri, Apr 07, 2006 at 11:31:40AM +0200, Michael Str=F6der wrote: > Timur Izhbulatov wrote: > > Also I would like to ask you to pay your attention to the issue I repor= ted some > > time ago: > > http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1440151&gr= oup_id=3D2072&atid=3D102072. > So if it's urgent for you to get your issue done I'd like to encourage > you to submit a patch. Even if your patch is not perfect this makes it > easier for me to start working on it. My patch for HEAD is attached. And, yes, it's not perfect, just a quick fix= =2E For example the ldap.ldapobject.SimpleLDAPObject.passwd method still doesn't re= turn server generated password if the newpw argument is omitted. > Maybe your requirement could be solved in the Python wrapper module > ldap.ldapobject. Not sure about it though. Not only in ldap.ldapobject. The problem is also in Modules/LDAPObject.c: l= _ldap_passwd > Please, stay tuned to the python-ldap-dev mailing list. I'm reading it > and will answer there. Maybe someone else on the list feels like taking > over the task. For those who are interested. More details can be found in my previous repo= rt: http://sourceforge.net/mailarchive/forum.php?thread_id=3D9546124&forum_id= =3D4346 Cheers, --=20 Timur Izhbulatov OILspace, 26 Leninskaya sloboda, bld. 2, 2nd floor, 115280 Moscow, Russia P:+7 495 105 7245 + ext.205 F:+7 495 105 7246 E:Tim...@oi... Building Successful Supply Chains - One Solution At A Time. www.oilspace.com |
From: <mi...@st...> - 2006-04-13 17:47:18
|
Timur Izhbulatov wrote: >=20 > On Fri, Apr 07, 2006 at 11:31:40AM +0200, Michael Str=F6der wrote: >=20 >>Timur Izhbulatov wrote: >=20 >>>Also I would like to ask you to pay your attention to the issue I repo= rted some >>>time ago: >>>http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1440151&g= roup_id=3D2072&atid=3D102072. >=20 >>So if it's urgent for you to get your issue done I'd like to encourage >>you to submit a patch. Even if your patch is not perfect this makes it >>easier for me to start working on it. >=20 > My patch for HEAD is attached. And, yes, it's not perfect, just a quick= fix. For > example the ldap.ldapobject.SimpleLDAPObject.passwd method still doesn'= t return > server generated password if the newpw argument is omitted. Timur, thanks for your patch. 1. As long as returning a server-generated password is not implemented it does not make sense to make newpw optional and/or accept None as value= . 2. Personally I'd like avoid to turn arguments user,oldpw,newpw of passwd() into optional key-word arguments (and we can't do that for only user and oldpw, see 1.). I'd rather prefer the application developer to really know what he's doing. But I'm open to other opinions. > For those who are interested. More details can be found in my previous = report: > http://sourceforge.net/mailarchive/forum.php?thread_id=3D9546124&forum_= id=3D4346 Ciao, Michael. |
From: Timur I. <Tim...@oi...> - 2006-04-14 11:15:49
|
On Thu, Apr 13, 2006 at 07:47:05PM +0200, Michael Str=F6der wrote: > Timur, thanks for your patch. >=20 > 1. As long as returning a server-generated password is not implemented > it does not make sense to make newpw optional and/or accept None as value. Agree. I just blindly followed the RFC. > 2. Personally I'd like avoid to turn arguments user,oldpw,newpw of > passwd() into optional key-word arguments (and we can't do that for only > user and oldpw, see 1.). I'd rather prefer the application developer to > really know what he's doing. But I'm open to other opinions. In this case the application developer won't be able to do some important things. For example, changing other users's passwords will be impossible ev= en if tha application is bound with root DN. And if you really don't like changing the passwd() method I suggest adding = new method or overriding the existing on in subclass. Of course, this implies my patch for LDAPObject.c. WDYT? --=20 Timur Izhbulatov OILspace, 26 Leninskaya sloboda, bld. 2, 2nd floor, 115280 Moscow, Russia P:+7 495 105 7245 + ext.205 F:+7 495 105 7246 E:Tim...@oi... Building Successful Supply Chains - One Solution At A Time. www.oilspace.com |
From: <mi...@st...> - 2006-04-16 10:47:08
|
Timur Izhbulatov wrote: > On Thu, Apr 13, 2006 at 07:47:05PM +0200, Michael Str=F6der wrote: >=20 >>1. As long as returning a server-generated password is not implemented >>it does not make sense to make newpw optional and/or accept None as val= ue. >=20 > Agree. I just blindly followed the RFC. If we can't make newpw an optional key-word argument we also can't make user and oldpw to optional key-word arguments. >>2. Personally I'd like avoid to turn arguments user,oldpw,newpw of >>passwd() into optional key-word arguments (and we can't do that for onl= y >>user and oldpw, see 1.). I'd rather prefer the application developer to >>really know what he's doing. But I'm open to other opinions. >=20 > In this case the application developer won't be able to do some importa= nt > things. For example, changing other users's passwords will be impossibl= e even if > tha application is bound with root DN. The developer could simply pass value None to passwd() for user and oldpw= . Ciao, Michael. |
From: Timur I. <Tim...@oi...> - 2006-04-16 12:24:22
|
On Sun, Apr 16, 2006 at 12:46:44PM +0200, Michael Str=F6der wrote: > Timur Izhbulatov wrote: > > On Thu, Apr 13, 2006 at 07:47:05PM +0200, Michael Str=F6der wrote: > >=20 > >>1. As long as returning a server-generated password is not implemented > >>it does not make sense to make newpw optional and/or accept None as val= ue. > >=20 > > Agree. I just blindly followed the RFC. >=20 > If we can't make newpw an optional key-word argument we also can't make > user and oldpw to optional key-word arguments. Yes, now I see. At this moment there is no point in making any of the arguments optional. > >>2. Personally I'd like avoid to turn arguments user,oldpw,newpw of > >>passwd() into optional key-word arguments (and we can't do that for only > >>user and oldpw, see 1.). I'd rather prefer the application developer to > >>really know what he's doing. But I'm open to other opinions. > >=20 > > In this case the application developer won't be able to do some importa= nt > > things. For example, changing other users's passwords will be impossibl= e even if > > tha application is bound with root DN. >=20 > The developer could simply pass value None to passwd() for user and oldpw. Passing None is OK as long as l_ldap_passwd() allows this. So I suggest app= lying my changes only to Modules/LDAPObject.c. Cheers, --=20 Timur Izhbulatov OILspace, 26 Leninskaya sloboda, bld. 2, 2nd floor, 115280 Moscow, Russia P:+7 495 105 7245 + ext.205 F:+7 495 105 7246 E:Tim...@oi... Building Successful Supply Chains - One Solution At A Time. www.oilspace.com |
From: <mi...@st...> - 2006-04-18 11:18:26
|
Timur Izhbulatov wrote: > On Sun, Apr 16, 2006 at 12:46:44PM +0200, Michael Str=F6der wrote: >=20 >>Timur Izhbulatov wrote: >> >>>On Thu, Apr 13, 2006 at 07:47:05PM +0200, Michael Str=F6der wrote: >>> >>>>2. Personally I'd like avoid to turn arguments user,oldpw,newpw of >>>>passwd() into optional key-word arguments (and we can't do that for o= nly >>>>user and oldpw, see 1.). I'd rather prefer the application developer = to >>>>really know what he's doing. But I'm open to other opinions. >>> >>>In this case the application developer won't be able to do some import= ant >>>things. For example, changing other users's passwords will be impossib= le even if >>>tha application is bound with root DN. >> >>The developer could simply pass value None to passwd() for user and old= pw. >=20 > Passing None is OK as long as l_ldap_passwd() allows this. So I suggest= applying > my changes only to Modules/LDAPObject.c. Ok, I've committed the patch below. Please test. Ciao, Michael Index: Modules/LDAPObject.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvsroot/python-ldap/python-ldap/Modules/LDAPObject.c,v retrieving revision 1.74 diff -u -r1.74 LDAPObject.c --- Modules/LDAPObject.c 5 Apr 2006 22:40:14 -0000 1.74 +++ Modules/LDAPObject.c 18 Apr 2006 11:12:24 -0000 @@ -1179,7 +1179,7 @@ int msgid; int ldaperror; - if (!PyArg_ParseTuple( args, "s#s#s#|OO", &user.bv_val, &user_len, &oldpw.bv_val, &oldpw_len, &newpw.bv_val, &newpw_len, &serverctrls, &clientctrls )) + if (!PyArg_ParseTuple( args, "z#z#z#|OO", &user.bv_val, &user_len, &oldpw.bv_val, &oldpw_len, &newpw.bv_val, &newpw_len, &serverctrls, &clientctrls )) return NULL; user.bv_len =3D (ber_len_t) user_len; @@ -1201,7 +1201,13 @@ } LDAP_BEGIN_ALLOW_THREADS( self ); - ldaperror =3D ldap_passwd( self->ldap, &user, &oldpw, &newpw, server_ldcs, client_ldcs, &msgid ); + ldaperror =3D ldap_passwd( self->ldap, + user.bv_val !=3D NULL ? &user : NULL, + oldpw.bv_val !=3D NULL ? &oldpw : NULL, + newpw.bv_val !=3D NULL ? &newpw : NULL, + server_ldcs, + client_ldcs, + &msgid ); LDAP_END_ALLOW_THREADS( self ); LDAPControl_List_DEL( server_ldcs ); |
From: Timur I. <Tim...@oi...> - 2006-04-19 06:50:54
|
On Tue, Apr 18, 2006 at 01:18:08PM +0200, Michael Str=F6der wrote: > Ok, I've committed the patch below. Please test. It is working. Thank you! --=20 Timur Izhbulatov OILspace, 26 Leninskaya sloboda, bld. 2, 2nd floor, 115280 Moscow, Russia P:+7 495 105 7245 + ext.205 F:+7 495 105 7246 E:Tim...@oi... Building Successful Supply Chains - One Solution At A Time. www.oilspace.com |