From it at crummock.com Wed Apr 11 10:21:03 2007 From: it at crummock.com (Ross McKerchar) Date: Wed, 11 Apr 2007 09:21:03 +0100 Subject: compiled ldap libs for win32/python 2.5 Message-ID: <461C9A6F.6030307@crummock.com> Hi, I've read a few posts about this already on the mailing list but nothing conclusive. Could somebody confirm for me: 1) Is it simply a case of getting someone to compile the current development code or is extra work needed on the codebase? 2) Is there a roadmap or commitment from anyone for releasing a win32 package in the future? I am curious as I have a win32/2.5 based app that could really do with some ldap functionality and if I can get the current status of project then I'll be in a better position to help... -ross From michael at stroeder.com Wed Apr 11 10:27:07 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 11 Apr 2007 10:27:07 +0200 Subject: compiled ldap libs for win32/python 2.5 In-Reply-To: <461C9A6F.6030307@crummock.com> References: <461C9A6F.6030307@crummock.com> Message-ID: <461C9BDB.2050506@stroeder.com> Ross, Ross McKerchar wrote: > > 1) Is it simply a case of getting someone to compile the current > development code or is extra work needed on the codebase? There should not be any effort needed on the codebase. > 2) Is there a roadmap or commitment from anyone for releasing a win32 > package in the future? Some people did Win32 builds before. But they did not keep up with Python and python-ldap development. And the builds did not support SASL functionality. > I am curious as I have a win32/2.5 based app that could really do with > some ldap functionality and if I can get the current status of project > then I'll be in a better position to help... Your help would be appreciated. Probably using MingW? Ciao, Michael. From it at crummock.com Wed Apr 11 11:37:27 2007 From: it at crummock.com (Ross McKerchar) Date: Wed, 11 Apr 2007 10:37:27 +0100 Subject: compiled ldap libs for win32/python 2.5 In-Reply-To: <461C9BDB.2050506@stroeder.com> References: <461C9A6F.6030307@crummock.com> <461C9BDB.2050506@stroeder.com> Message-ID: <461CAC57.4030307@crummock.com> Michael Str?der wrote: >> I am curious as I have a win32/2.5 based app that could really do with >> some ldap functionality and if I can get the current status of project >> then I'll be in a better position to help... > > Your help would be appreciated. Probably using MingW? Hi Michael, I've just been investigating this and, although I'm not a complete stranger to building with MingW, my initial findings are that I'm a bit out of my depth. Statements like 'Cyrus SASL on Windows is still laregely a "work in progress"' and Jonathan Bowman's experiences (http://sourceforge.net/mailarchive/message.php?msg_name=7a2b5dfb0702100528t64cfeaf0gd7859338f998a0d0%40mail.gmail.com) suggest that I am very unlikely to succesfully navigate my with through such unfamiliar territory in a reasonable time-frame. I am, however, in a position to offer a donation to the project, if that would allow someone with more experience than me to complete the build (any takers?). Alternatively I am willing to be persuaded that the DIY option isn't as tricky as appears, so if someone is willing to offer me some extended pointers they would be greatly appreciated. -ross From michael at stroeder.com Wed Apr 11 13:03:59 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 11 Apr 2007 13:03:59 +0200 Subject: compiled ldap libs for win32/python 2.5 In-Reply-To: <461CAC57.4030307@crummock.com> References: <461C9A6F.6030307@crummock.com> <461C9BDB.2050506@stroeder.com> <461CAC57.4030307@crummock.com> Message-ID: <461CC09F.4070905@stroeder.com> Ross McKerchar wrote: > Michael Str?der wrote: >>> I am curious as I have a win32/2.5 based app that could really do >>> with some ldap functionality and if I can get the current status of >>> project then I'll be in a better position to help... >> >> Your help would be appreciated. Probably using MingW? > > I've just been investigating this and, although I'm not a complete > stranger to building with MingW, my initial findings are that I'm a bit > out of my depth. Statements like 'Cyrus SASL on Windows is still > laregely a "work in progress"' You'd probably should start asking on openldap-software mailing list how to build OpenLDAP client libs and all required libs for Win32 with MingW (MSYS). Symas is doing this. Rich Megginson wrote this: http://wiki.mozilla.org/LDAP_C_SDK_SASL_Windows See also current related discussion in news:mozilla.dev.tech.ldap Ciao, Michael. From michael at stroeder.com Wed Apr 11 13:03:59 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 11 Apr 2007 13:03:59 +0200 Subject: compiled ldap libs for win32/python 2.5 In-Reply-To: <461CAC57.4030307@crummock.com> References: <461C9A6F.6030307@crummock.com> <461C9BDB.2050506@stroeder.com> <461CAC57.4030307@crummock.com> Message-ID: <461CC09F.4070905@stroeder.com> Ross McKerchar wrote: > Michael Str?der wrote: >>> I am curious as I have a win32/2.5 based app that could really do >>> with some ldap functionality and if I can get the current status of >>> project then I'll be in a better position to help... >> >> Your help would be appreciated. Probably using MingW? > > I've just been investigating this and, although I'm not a complete > stranger to building with MingW, my initial findings are that I'm a bit > out of my depth. Statements like 'Cyrus SASL on Windows is still > laregely a "work in progress"' You'd probably should start asking on openldap-software mailing list how to build OpenLDAP client libs and all required libs for Win32 with MingW (MSYS). Symas is doing this. Rich Megginson wrote this: http://wiki.mozilla.org/LDAP_C_SDK_SASL_Windows See also current related discussion in news:mozilla.dev.tech.ldap Ciao, Michael. From d at adaptive-enterprises.com.au Wed Apr 11 13:44:03 2007 From: d at adaptive-enterprises.com.au (David Leonard) Date: Wed, 11 Apr 2007 21:44:03 +1000 Subject: compiled ldap libs for win32/python 2.5 In-Reply-To: <461CC09F.4070905@stroeder.com> References: <461C9A6F.6030307@crummock.com> <461C9BDB.2050506@stroeder.com> <461CAC57.4030307@crummock.com> <461CC09F.4070905@stroeder.com> Message-ID: <461CCA03.6050202@adaptive-enterprises.com.au> it might be possible to modify python-ldap to work with wldap32.dll and avoid openldap on win32. (see 'references' at http://msdn2.microsoft.com/en-us/library/aa367008.aspx) mingw comes with a winldap.h, but I don't know how close it is to the one that comes from the official platform sdk headers. python's distutils supports mingw, so this path looks quite attractive. d Michael Str?der wrote: > Ross McKerchar wrote: > >> Michael Str?der wrote: >> >>>> I am curious as I have a win32/2.5 based app that could really do >>>> with some ldap functionality and if I can get the current status of >>>> project then I'll be in a better position to help... >>>> >>> Your help would be appreciated. Probably using MingW? >>> >> I've just been investigating this and, although I'm not a complete >> stranger to building with MingW, my initial findings are that I'm a bit >> out of my depth. Statements like 'Cyrus SASL on Windows is still >> laregely a "work in progress"' >> > > You'd probably should start asking on openldap-software mailing list how > to build OpenLDAP client libs and all required libs for Win32 with MingW > (MSYS). Symas is doing this. > > Rich Megginson wrote this: > http://wiki.mozilla.org/LDAP_C_SDK_SASL_Windows > > See also current related discussion in news:mozilla.dev.tech.ldap > > Ciao, Michael. > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Python-LDAP-dev mailing list > Python-LDAP-dev at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/python-ldap-dev > > -- David Leonard d at adaptive-enterprises.com.au Ph:+61 404 844 850 -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Thu Apr 12 14:01:14 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 12 Apr 2007 14:01:14 +0200 Subject: compiled ldap libs for win32/python 2.5 In-Reply-To: <461CCA03.6050202@adaptive-enterprises.com.au> References: <461C9A6F.6030307@crummock.com> <461C9BDB.2050506@stroeder.com> <461CAC57.4030307@crummock.com> <461CC09F.4070905@stroeder.com> <461CCA03.6050202@adaptive-enterprises.com.au> Message-ID: <461E1F8A.7060503@stroeder.com> David Leonard wrote: > it might be possible to modify python-ldap to work with wldap32.dll and > avoid openldap on win32. We had a thread on this list with subject "winldap?" back in 12/2006. My main concern is who is going to provide *continous* support for this? Personally I can't. Also I suspect that different versions of wldap32.dll have different feature sets. I don't have enough knowledge about that. > python's distutils supports mingw, so this path looks quite attractive. I don't want to hold anybody back, but I'd like to remind everybody hacking in this direction to think about who is going to maintain this code for the next two years or so. I'd suggest to create a completely separate C module called _winldap for that purpose. And given that we e.g. added support for OpenLDAP's ldap_str2dn() the gap between OpenLDAP libs and other vendor's LDAP libs gets bigger. And how about extended controls? Ciao, Michael. From mcicogni at libero.it Mon Apr 16 19:18:13 2007 From: mcicogni at libero.it (Mauro Cicognini) Date: Mon, 16 Apr 2007 19:18:13 +0200 Subject: compiled ldap libs for win32/python 2.5 In-Reply-To: <461CAC57.4030307@crummock.com> References: <461C9A6F.6030307@crummock.com> <461C9BDB.2050506@stroeder.com> <461CAC57.4030307@crummock.com> Message-ID: <4623AFD5.80602@libero.it> Ross McKerchar wrote: > Statements like 'Cyrus SASL on Windows is still laregely a "work in progress"' and Jonathan Bowman's experiences (http://sourceforge.net/mailarchive/message.php?msg_name=7a2b5dfb0702100528t64cfeaf0gd7859338f998a0d0%40mail.gmail.com) > suggest that I am very unlikely to succesfully navigate my with through such unfamiliar territory in a reasonable time-frame. > I have built Python-LDAP on Windows in the past, and this should just mean that you'd have to exclude SASL from the targets, i.e. no support for SASL on Windows (just as Michael correctly pointed out). How unfortunate this could be in your situation, I don't know. > Alternatively I am willing to be persuaded that the DIY option isn't as tricky as appears, so if someone is willing to offer me some extended pointers they would be greatly appreciated. It isn't _really_ tricky, at least not as tricky as it used to be when OpenLDAP didn't support Windows natively. Now it's just a matter of downloading the sources (Python, OpenLDAP, OpenSSL, BDB, Python-LDAP), setting up your MinGW build environment, and launching "make" (wait a while). Note that you don't need to build Python, nor BDB, but you'll need some headers; and you'll only need shared libraries, headers and libs from OpenLDAP and OpenSSL, not the whole OpenLDAP thing (most of all not slurpd, which did not build at all on my Windows box last time). The whole activity does take a while, though, last time I could afford the time I used a couple days interspersed in a week of real work. HTH Mauro From michael at stroeder.com Mon Apr 30 16:17:03 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 30 Apr 2007 16:17:03 +0200 Subject: FYI: Linuxtag 2007 and LDAPcon 2007 Message-ID: <4635FA5F.1080900@stroeder.com> HI! once again OpenLDAP will be presented by a team of volunteers at Linuxtag 2007 in Berlin, Germany. http://www.linuxtag.org/2007/ Several deployment scenarios based on OpenLDAP will be demonstrated with various LDAP clients. I will also present web2ldap and answer questions about python-ldap too. I'd be glad to meet members of the community personally there. I'd also like to inform everybody here about a LDAP directory conference being held at September 06/07, 2007 in Cologne, Germany. If you'd like to present your work please see call for papers on the conference's web site: http://www.guug.de/veranstaltungen/ldapcon2007/ I'd be glad to meet some of you there. Ciao, Michael. -- Michael Str?der E-Mail: michael at stroeder.com http://www.stroeder.com From sylvain.thenault at logilab.fr Wed May 2 13:13:46 2007 From: sylvain.thenault at logilab.fr (Sylvain =?iso-8859-1?Q?Th=E9nault?=) Date: Wed, 2 May 2007 13:13:46 +0200 Subject: [Fwd: Active directory signature] Message-ID: <20070502111346.GC12924@crater.logilab.fr> forwarding this message since I'm now subscribed. ----- Forwarded message from Sylvain Th?nault ----- > From: Sylvain Th?nault > To: python-ldap-dev at lists.sourceforge.net > Date: Wed, 2 May 2007 13:10:39 +0200 > Subject: Active directory signature > > Hi there ! > > I've some customer code which has been recently broken, since they > upgraded to AD3. It's some basic authentication code using python-ldap > (I'm not sure which version is installed on their servers). Their > microsoft expert told them it was because they changed the "Domain > controller: LDAP server signing requirements" option to "Require signing", > which I can beleive... Is this supported by python-ldap ? If so does > someone has an idea about what should I change to make it work again ? > > Sorry if this question has already been asked but all I get from sf > servers hosting mailing list archives is internal server error :( > > PS: please CC me I'm not subscribed to the list > -- > Sylvain Th?nault LOGILAB, Paris (France) > Formations Python, Zope, Plone, Debian: http://www.logilab.fr/formations > D?veloppement logiciel sur mesure: http://www.logilab.fr/services > Python et calcul scientifique: http://www.logilab.fr/science > ----- End forwarded message ----- -- Sylvain Th?nault LOGILAB, Paris (France) Formations Python, Zope, Plone, Debian: http://www.logilab.fr/formations D?veloppement logiciel sur mesure: http://www.logilab.fr/services Python et calcul scientifique: http://www.logilab.fr/science From garlandkr at gmail.com Wed May 2 15:13:36 2007 From: garlandkr at gmail.com (Garland, Ken R) Date: Wed, 2 May 2007 09:13:36 -0400 Subject: [Fwd: Active directory signature] In-Reply-To: <20070502111346.GC12924@crater.logilab.fr> References: <20070502111346.GC12924@crater.logilab.fr> Message-ID: On 5/2/07, Sylvain Th?nault wrote: > forwarding this message since I'm now subscribed. > > ----- Forwarded message from Sylvain Th?nault ----- > > > From: Sylvain Th?nault > > To: python-ldap-dev at lists.sourceforge.net > > Date: Wed, 2 May 2007 13:10:39 +0200 > > Subject: Active directory signature > > > > Hi there ! > > > > I've some customer code which has been recently broken, since they > > upgraded to AD3. It's some basic authentication code using python-ldap > > (I'm not sure which version is installed on their servers). Their > > microsoft expert told them it was because they changed the "Domain > > controller: LDAP server signing requirements" option to "Require signing", basically saying they now require authentication. you just need to determine what credentials have been setup to allow whatev er task it is you want to accomplish, then specify them inside your python-ldap program. something similar to: l=ldap.initialize("ldap://your.server.com") l.bind('cn=the_cn_you_use,dc=server,dc=com', 'password') change 'cn' to 'uid' or whatever it is that your bind requires. set that to a user which has permissions to do whatever it is you are trying to do, simple searches, modifying entries, etc. > > which I can beleive... Is this supported by python-ldap ? If so does > > someone has an idea about what should I change to make it work again ? > > > > Sorry if this question has already been asked but all I get from sf > > servers hosting mailing list archives is internal server error :( > > > > PS: please CC me I'm not subscribed to the list > > -- > > Sylvain Th?nault LOGILAB, Paris (France) > > Formations Python, Zope, Plone, Debian: http://www.logilab.fr/formations > > D?veloppement logiciel sur mesure: http://www.logilab.fr/services > > Python et calcul scientifique: http://www.logilab.fr/science > > > > ----- End forwarded message ----- > > -- > Sylvain Th?nault LOGILAB, Paris (France) > Formations Python, Zope, Plone, Debian: http://www.logilab.fr/formations > D?veloppement logiciel sur mesure: http://www.logilab.fr/services > Python et calcul scientifique: http://www.logilab.fr/science > > > From sylvain.thenault at logilab.fr Wed May 2 15:21:08 2007 From: sylvain.thenault at logilab.fr (Sylvain =?iso-8859-1?Q?Th=E9nault?=) Date: Wed, 2 May 2007 15:21:08 +0200 Subject: [Fwd: Active directory signature] In-Reply-To: References: <20070502111346.GC12924@crater.logilab.fr> Message-ID: <20070502132108.GJ12924@crater.logilab.fr> On Wednesday 02 May ? 09:13, Garland, Ken R wrote: > On 5/2/07, Sylvain Th?nault wrote: > >forwarding this message since I'm now subscribed. > > > >----- Forwarded message from Sylvain Th?nault > > ----- > > > >> From: Sylvain Th?nault > >> To: python-ldap-dev at lists.sourceforge.net > >> Date: Wed, 2 May 2007 13:10:39 +0200 > >> Subject: Active directory signature > >> > >> Hi there ! > >> > >> I've some customer code which has been recently broken, since they > >> upgraded to AD3. It's some basic authentication code using python-ldap > >> (I'm not sure which version is installed on their servers). Their > >> microsoft expert told them it was because they changed the "Domain > >> controller: LDAP server signing requirements" option to "Require > >signing", > > > basically saying they now require authentication. you just need to > determine what credentials have been setup to allow whatev er task it > is you want to accomplish, then specify them inside your python-ldap > program. something similar to: > > l=ldap.initialize("ldap://your.server.com") > l.bind('cn=the_cn_you_use,dc=server,dc=com', 'password') > > change 'cn' to 'uid' or whatever it is that your bind requires. set > that to a user which has permissions to do whatever it is you are > trying to do, simple searches, modifying entries, etc. This is already what is done. Basically the code is only doing authentification, no more, and works that way, given a login/password to authenticate: 1. search in AD the DN corresponding to the login, using an authenticated connection (using an admin dn/password) 2. try to connect using the found DN and the given password (using simple_bind_s) to validate the password Maybe this is not the right way to do AD/LDAP authentication though ? -- Sylvain Th?nault LOGILAB, Paris (France) Formations Python, Zope, Plone, Debian: http://www.logilab.fr/formations D?veloppement logiciel sur mesure: http://www.logilab.fr/services Python et calcul scientifique: http://www.logilab.fr/science From sylvain.thenault at logilab.fr Wed May 2 18:57:50 2007 From: sylvain.thenault at logilab.fr (Sylvain =?iso-8859-1?Q?Th=E9nault?=) Date: Wed, 2 May 2007 18:57:50 +0200 Subject: [Fwd: Active directory signature] In-Reply-To: <20070502132108.GJ12924@crater.logilab.fr> References: <20070502111346.GC12924@crater.logilab.fr> <20070502132108.GJ12924@crater.logilab.fr> Message-ID: <20070502165750.GN12924@crater.logilab.fr> FYI, I'v fixed the problem which was actually due to auto chasing for referal, causing an anonymous connection to be open. Thank you On Wednesday 02 May ? 15:21, Sylvain Th?nault wrote: > On Wednesday 02 May ? 09:13, Garland, Ken R wrote: > > On 5/2/07, Sylvain Th?nault wrote: > > >forwarding this message since I'm now subscribed. > > > > > >----- Forwarded message from Sylvain Th?nault > > > ----- > > > > > >> From: Sylvain Th?nault > > >> To: python-ldap-dev at lists.sourceforge.net > > >> Date: Wed, 2 May 2007 13:10:39 +0200 > > >> Subject: Active directory signature > > >> > > >> Hi there ! > > >> > > >> I've some customer code which has been recently broken, since they > > >> upgraded to AD3. It's some basic authentication code using python-ldap > > >> (I'm not sure which version is installed on their servers). Their > > >> microsoft expert told them it was because they changed the "Domain > > >> controller: LDAP server signing requirements" option to "Require > > >signing", > > > > > > basically saying they now require authentication. you just need to > > determine what credentials have been setup to allow whatev er task it > > is you want to accomplish, then specify them inside your python-ldap > > program. something similar to: > > > > l=ldap.initialize("ldap://your.server.com") > > l.bind('cn=the_cn_you_use,dc=server,dc=com', 'password') > > > > change 'cn' to 'uid' or whatever it is that your bind requires. set > > that to a user which has permissions to do whatever it is you are > > trying to do, simple searches, modifying entries, etc. > > This is already what is done. Basically the code is only doing > authentification, no more, and works that way, given a login/password > to authenticate: > 1. search in AD the DN corresponding to the login, using an > authenticated connection (using an admin dn/password) > 2. try to connect using the found DN and the given password (using > simple_bind_s) to validate the password > > Maybe this is not the right way to do AD/LDAP authentication though ? -- Sylvain Th?nault LOGILAB, Paris (France) Formations Python, Zope, Plone, Debian: http://www.logilab.fr/formations D?veloppement logiciel sur mesure: http://www.logilab.fr/services Python et calcul scientifique: http://www.logilab.fr/science From aurynn at gmail.com Wed May 2 20:17:07 2007 From: aurynn at gmail.com (Aurynn Shaw) Date: Wed, 2 May 2007 12:17:07 -0600 Subject: Parsing a .schema file Message-ID: Hi, everyone; I'm trying to parse a foo.schema file, which appears to be in the attributetype ( 1.3.6.1.4.1.11940.1 NAME 'startDate' DESC 'Flash Code user subscription start date' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) style format, instead of LDIF. ldap.schema seems to indicate that it can parse LDAP schemas. Is that in this format, or does it require a connection to the LDAP server? Could I get some examples on how to do what I'm looking for? I'm wanting to generate SQL CREATE TABLE statements directly from the LDAP schema, which will hopefully save a lot of time in migrating my backend to postgres. Thank you, Aurynn From michael at stroeder.com Wed May 2 23:46:53 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 02 May 2007 23:46:53 +0200 Subject: Parsing a .schema file In-Reply-To: References: Message-ID: <463906CD.5040701@stroeder.com> Aurynn Shaw wrote: > > I'm trying to parse a foo.schema file, which appears to be in the > > attributetype ( 1.3.6.1.4.1.11940.1 > NAME 'startDate' > DESC 'Flash Code user subscription start date' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) > > style format, instead of LDIF. > > ldap.schema seems to indicate that it can parse LDAP schemas. Is that > in this format, or does it require a connection to the LDAP server? Mind the line-wrapping: Python 2.5.1 (r251:54863, Apr 19 2007, 12:23:24) [GCC 4.1.2 20061115 (prerelease) (SUSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> a="""attributetype ( 1.3.6.1.4.1.11940.1 ... NAME 'startDate' ... DESC 'Flash Code user subscription start date' ... EQUALITY caseIgnoreMatch ... SUBSTR caseIgnoreSubstringsMatch ... SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) ... """ >>> import ldap.schema >>> at=ldap.schema.AttributeType(a[len('attributetype '):].replace('\n',' ')) >>> at >>> dir(at) ['__doc__', '__init__', '__module__', '__str__', '_set_attrs', 'collective', 'desc', 'equality', 'get_id', 'key_attr', 'key_list', 'names', 'no_user_mod', 'obsolete', 'oid', 'ordering', 'schema_attribute', 'set_id', 'single_value', 'substr', 'sup', 'syntax', 'syntax_len', 'token_defaults', 'usage'] Same for other schema elements. Ciao, Michael. From inopua at gmail.com Fri May 4 14:33:41 2007 From: inopua at gmail.com (Ino Heatwave) Date: Fri, 4 May 2007 14:33:41 +0200 Subject: possible bug(s) in python-ldap sasl code Message-ID: <11a7ea430705040533q3b93a7c1o4e84d32b4bd3f38b@mail.gmail.com> Hi, Im currently testing out python-ldap and Im connecting to an active directory service. Binding works ok, but searching usually (usually as in I cant remember if it has worked at one point in time or not) ends with an error ("00000000: LdapErr: DSID-0C090627, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, vece"). The data, however is received when I use the library asynchronously. (I.e it sends me the search results, then raises the exception). I could provide sample code that gives me this behaviour. Writing a custom search method that masks this error works great though, but feels kinda ugly... But my main problem is: I cant bind with two different LDAPObjects on the same server. E.g creating two connections to the same server, using sasl bind (digest-md5). The latter bind operation always raises " ldap.INVALID_CREDENTIALS: {'info': '00090313: LdapErr: DSID-0C09043E, comment: AcceptSecurityContext error, data 0, vece', 'desc': 'Invalid credentials'}", even though the username/password are identical. Again, I could provide some sample code that shows this behaviour if you're interested. Connecting with two ldapobjects to the same server and binding works fine with TLS though, but it would certainly be a lot better if we could have support for this through sasl. Any ideas? -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Fri May 4 23:09:57 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 04 May 2007 23:09:57 +0200 Subject: possible bug(s) in python-ldap sasl code In-Reply-To: <11a7ea430705040533q3b93a7c1o4e84d32b4bd3f38b@mail.gmail.com> References: <11a7ea430705040533q3b93a7c1o4e84d32b4bd3f38b@mail.gmail.com> Message-ID: <463BA125.3030601@stroeder.com> Ino Heatwave wrote: > > Im currently testing out python-ldap and Im connecting to an active > directory service. > > Binding works ok, but searching usually (usually as in I cant remember > if it has worked at one point in time or not) ends with an error > ("00000000: LdapErr: DSID-0C090627, comment: In order to perform this > operation a successful bind must be completed on the connection., data > 0, vece"). Yes. For most entries there is no anonymous access allowed in the default installation of Active Directory. > The data, however is received when I use the library > asynchronously. >( I.e it sends me the search results, then raises the > exception). Some entries are accessible even with anon access. But without knowing how your code looks like it's hard to tell what happens. > I could provide sample code that gives me this behaviour. Yes, please provide simple test code demonstrating your issue. > Writing a custom search method that masks this error works great though, > but feels kinda ugly... ??? > But my main problem is: I cant bind with two different LDAPObjects on > the same server. Are your sure? I'm doing this all the time with web2ldap. > E.g creating two connections to the same server, using > sasl bind (digest-md5). The latter bind operation always raises > "ldap.INVALID_CREDENTIALS: {'info': '00090313: LdapErr: DSID-0C09043E, > comment: AcceptSecurityContext error, data 0, vece', 'desc': 'Invalid > credentials'}", even though the username/password are identical. Again, > I could provide some sample code that shows this behaviour if you're > interested. Please provide a simple example demostrating the problem. The following code works for me with OpenLDAP 2.3.35: --------------------------- snip --------------------------- import ldap,ldap.sasl trace_level=2 ldapcon1 = ldap.initialize('ldap://localhost:1390',trace_level=trace_level) #ldapcon1.simple_bind_s('cn=Fred Feuerstein,ou=Testing,dc=stroeder,dc=de','fredsecret') sasl_auth = ldap.sasl.sasl({ ldap.sasl.CB_AUTHNAME :'fred', ldap.sasl.CB_PASS :'fredsecret', },'DIGEST-MD5') ldapcon1.sasl_interactive_bind_s("", sasl_auth) ldapcon1.search_s('',ldap.SCOPE_BASE) ldapcon2 = ldap.initialize('ldap://localhost:1390',trace_level=trace_level) #ldapcon2.simple_bind_s('uid=anna,ou=Testing,dc=stroeder,dc=de','annasecret') sasl_auth = ldap.sasl.sasl({ ldap.sasl.CB_AUTHNAME :'anna', ldap.sasl.CB_PASS :'annasecret', },'DIGEST-MD5') ldapcon2.sasl_interactive_bind_s("", sasl_auth) ldapcon1.search_s('',ldap.SCOPE_BASE) --------------------------- snip --------------------------- > Any ideas? Use trace_level to examine what your code really does... ;-) Ciao, Michael. From inopua at gmail.com Sat May 5 01:43:45 2007 From: inopua at gmail.com (Ino Pua) Date: Sat, 5 May 2007 01:43:45 +0200 Subject: possible bug(s) in python-ldap sasl code In-Reply-To: <463BA125.3030601@stroeder.com> References: <11a7ea430705040533q3b93a7c1o4e84d32b4bd3f38b@mail.gmail.com> <463BA125.3030601@stroeder.com> Message-ID: <> Thanks a lot for your swift response, I hope you can bear with me with my somewhat funky and ugly code, and appreciate all help/advice/ pointers I can get :) For viewing (dis)pleasure, I nested my response: On 04 May 2007, at 23:09, Michael Str?der wrote: > Ino Heatwave wrote: >> >> Im currently testing out python-ldap and Im connecting to an active >> directory service. >> >> Binding works ok, but searching usually (usually as in I cant >> remember >> if it has worked at one point in time or not) ends with an error >> ("00000000: LdapErr: DSID-0C090627, comment: In order to perform this >> operation a successful bind must be completed on the connection., >> data >> 0, vece"). > > Yes. For most entries there is no anonymous access allowed in the > default installation of Active Directory. Well, the problem is that I've already bound as a user with the needed rights to search (even tried with Administrator, and I still get the error). > > Some entries are accessible even with anon access. But without knowing > how your code looks like it's hard to tell what happens. You certainly may be at the heart of the problem here, but is there any way, using the python-ldap api to ignore errors like that? Like saying: "ok, I realize I might not have access to everything in the directory as this user, but at least return what I have access to"? > >> I could provide sample code that gives me this behaviour. > > Yes, please provide simple test code demonstrating your issue. Below is an ugly example I've cooked up for the purpose: [[ look for attachment named ldap_simple_test.py ]] > >> But my main problem is: I cant bind with two different LDAPObjects on >> the same server. > > Are your sure? I'm doing this all the time with web2ldap. > >> E.g creating two connections to the same server, using >> sasl bind (digest-md5). The latter bind operation always raises >> "ldap.INVALID_CREDENTIALS: {'info': '00090313: LdapErr: >> DSID-0C09043E, >> comment: AcceptSecurityContext error, data 0, vece', 'desc': 'Invalid >> credentials'}", even though the username/password are identical. >> Again, >> I could provide some sample code that shows this behaviour if you're >> interested. > > Please provide a simple example demostrating the problem. > > The following code works for me with OpenLDAP 2.3.35: And the exact same code (modified only to fit with my server parameters of course) bails out with the exception. I've attached the code I ran and the results, seen from the command line with trace_level = 3. I've done some further testing, and using two different python processes to make two connections to the same server at the same time works ok, so there definately is something going on here. Is there some other way to trace whats going on that would make any sense to any of us? Im running this on OS X 10.4.9, with the lastest python-ldap (2.3) built against OpenLDAP 2.3.34. The AD servers Im trying against are Windows server 2003 instances. -------------- next part -------------- A non-text attachment was scrubbed... Name: ldap_simple_test.py Type: text/x-python-script Size: 1349 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ldap_two_test.py Type: text/x-python-script Size: 549 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ldap_two_test.trace.txt URL: From einar.nass.jensen at gmail.com Wed May 9 15:18:15 2007 From: einar.nass.jensen at gmail.com (=?ISO-8859-1?Q?Einar_N=E6ss_Jensen?=) Date: Wed, 9 May 2007 15:18:15 +0200 Subject: error when build and install Message-ID: <4e9e1220705090618k2697c2d1sa34387086b32f04b@mail.gmail.com> trying to build on debian etch, with ssl, I get this error: ldap-python version is 2.3 python-version is 2.4.4 openssl and sasl are installed Modules/constants.c: In function ?LDAPinit_constants?: Modules/constants.c:178: error: ?LDAP_OPT_X_TLS_CRLCHECK? undeclared (first use in this function) Modules/constants.c:178: error: (Each undeclared identifier is reported only once Modules/constants.c:178: error: for each function it appears in.) Modules/constants.c:179: error: ?LDAP_OPT_X_TLS_CRL_NONE? undeclared (first use in this function) Modules/constants.c:180: error: ?LDAP_OPT_X_TLS_CRL_PEER? undeclared (first use in this function) Modules/constants.c:181: error: ?LDAP_OPT_X_TLS_CRL_ALL? undeclared (first use in this function) Modules/constants.c:207: error: ?LDAP_AVA_NULL? undeclared (first use in this function) error: command 'gcc' failed with exit status 1 I have an earlier version of python-ldap, 2.0-pre19 (I I remember correctly) which is no trouble at all installing. any help apreciated Best regards -- -- Einar N?ss Jensen http://einarblog.homemade.no/einarblog http://www.homemade.no tlf: +47 90990249 (\__/) (='.'=)This is Bunny. Copy and paste bunny into your (")_(")signature to help him gain world domination. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vela at debian.org Wed May 9 17:13:40 2007 From: vela at debian.org (Matej Vela) Date: Wed, 09 May 2007 17:13:40 +0200 Subject: error when build and install In-Reply-To: <4e9e1220705090618k2697c2d1sa34387086b32f04b@mail.gmail.com> (Einar =?iso-8859-1?Q?N=E6ss?= Jensen's message of "Wed, 9 May 2007 15:18:15 +0200") References: <4e9e1220705090618k2697c2d1sa34387086b32f04b@mail.gmail.com> Message-ID: <87fy66t4gr.fsf@slavuj.carpriv.carnet.hr> "Einar N?ss Jensen" writes: > trying to build on debian etch, with ssl, I get this error: > ldap-python version is 2.3 > python-version is 2.4.4 > openssl and sasl are installed > > Modules/constants.c: In function *LDAPinit_constants*: > Modules/constants.c:178: error: *LDAP_OPT_X_TLS_CRLCHECK* undeclared > (first use in this function) [...] > > I have an earlier version of python-ldap, 2.0-pre19 (I I remember > correctly) which is no trouble at all installing. The current version of python-ldap requires version 2.3.0 of OpenLDAP libraries, while Etch provides 2.1.30. (AFAIK, this is mostly due to compatibility problems that would arise if an application simultaneously used differing versions of libldap and libnss-ldap. Etch does ship with slapd 2.3.30.) If you don't mind using a slightly older version (2.2.1), simply install the Debian package: # apt-get install python-ldap If you'd like to compile your own, apply the Debian patch from . Cheers, Matej From michael at stroeder.com Thu May 10 11:39:29 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 10 May 2007 11:39:29 +0200 Subject: Debian patches (was: error when build and install) In-Reply-To: <87fy66t4gr.fsf@slavuj.carpriv.carnet.hr> References: <4e9e1220705090618k2697c2d1sa34387086b32f04b@mail.gmail.com> <87fy66t4gr.fsf@slavuj.carpriv.carnet.hr> Message-ID: <4642E851.6070907@stroeder.com> Matej Vela wrote: > > If you'd like to compile your own, apply the Debian patch from > . This is quite a large patch set. I worry that somebody here claims to use python-ldap 2.3 but it's heavily patched like this. => I won't give support to Debian users anymore. I simply can't overlook all the changes made therein. Note that even OpenLDAP 2.2 is set to historic status by its developers. 2.1 is unmaintained since years. So there are currently no more fixes to OpenLDAP 2.2 and prior versions anymore. This also affects the client libs. Instead of putting so much effort into preserving backwards compability of python-ldap to OpenLDAP 2.1 you should rather do the work to consequenty update all Debian packages to use OpenLDAP 2.3. There have been so many important fixes in the client libs. Ciao, Michael. From michael at stroeder.com Thu May 10 11:46:45 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 10 May 2007 11:46:45 +0200 Subject: possible bug(s) in python-ldap sasl code In-Reply-To: References: <11a7ea430705040533q3b93a7c1o4e84d32b4bd3f38b@mail.gmail.com> <463BA125.3030601@stroeder.com> Message-ID: <4642EA05.5010705@stroeder.com> Ino Pua wrote: > > Is there some other way to trace whats going on that would make any > sense to any of us? Im running this on OS X 10.4.9, with the lastest > python-ldap (2.3) built against OpenLDAP 2.3.34. Did you also build OpenLDAP from scratch? With which SASL libs? Ciao, Michael. From vela at debian.org Thu May 10 13:43:31 2007 From: vela at debian.org (Matej Vela) Date: Thu, 10 May 2007 13:43:31 +0200 Subject: Debian patches In-Reply-To: <4642E851.6070907@stroeder.com> (Michael =?iso-8859-1?Q?Str?= =?iso-8859-1?Q?=F6der's?= message of "Thu, 10 May 2007 11:39:29 +0200") References: <4e9e1220705090618k2697c2d1sa34387086b32f04b@mail.gmail.com> <87fy66t4gr.fsf@slavuj.carpriv.carnet.hr> <4642E851.6070907@stroeder.com> Message-ID: <87tzukvr8c.fsf@slavuj.carpriv.carnet.hr> Michael Str?der writes: > Matej Vela wrote: > >> If you'd like to compile your own, apply the Debian patch from >> . > > This is quite a large patch set. I worry that somebody here claims to > use python-ldap 2.3 but it's heavily patched like this. I'm not sure how closely you looked, but most of it is packaging-related -- the equivalent of an RPM .spec file. debian/patches/openldap_2.1.diff is the one exception, and it's less that 3 KB. Apart from disabling unsupported option flags (LDAP_OPT_X_TLS_*), I don't think it significantly alters functionality. > => I won't give support to Debian users anymore. I simply can't overlook > all the changes made therein. I understand. Feel free to direct queries from Debian and Ubuntu users to . As you can see, I already keep an eye on python-ldap-dev. > Note that even OpenLDAP 2.2 is set to historic status by its developers. > 2.1 is unmaintained since years. So there are currently no more fixes to > OpenLDAP 2.2 and prior versions anymore. This also affects the client libs. > > Instead of putting so much effort into preserving backwards compability > of python-ldap to OpenLDAP 2.1 you should rather do the work to > consequenty update all Debian packages to use OpenLDAP 2.3. There have > been so many important fixes in the client libs. I know. Hopefully this will be fixed in the next release. Cheers, Matej From aspineux at gmail.com Wed May 23 19:16:00 2007 From: aspineux at gmail.com (Alain Spineux) Date: Wed, 23 May 2007 19:16:00 +0200 Subject: unicode value Message-ID: <71fe4e760705231016y24e8ca5ekcca2e6b37a4699f4@mail.gmail.com> Why does python-ldap not convert automatically any unicode string into UTF-8 before to call the raw function ? Is-it by design or just a lack of time ? The idea is to replace any argument using this function. def convert2raw(st): if isinstance(st, types.UnicodeType) return st.encode('utf-8') else return st Easy for the filter argument of the "search" function, more work for structure used by "modify" and other, but still easy ? This way we keep compatibility with older code. Any comment ? Ops: don't forget to make the the decoding of ldap result :-) Best regards -- -- Alain Spineux aspineux gmail com May the sources be with you From michael at stroeder.com Wed May 23 23:54:22 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 23 May 2007 23:54:22 +0200 Subject: unicode value In-Reply-To: <71fe4e760705231016y24e8ca5ekcca2e6b37a4699f4@mail.gmail.com> References: <71fe4e760705231016y24e8ca5ekcca2e6b37a4699f4@mail.gmail.com> Message-ID: <4654B80E.3080208@stroeder.com> Alain Spineux wrote: > Why does python-ldap not convert automatically any unicode string into > UTF-8 before > to call the raw function ? > > Is-it by design or just a lack of time ? Kind of a FAQ. Feel free to propose a patch with a good(!) solution. https://sourceforge.net/tracker/?func=detail&atid=352072&aid=616567&group_id=2072 Being the author of a schema-aware LDAP client based on python-ldap I know in how many detail problems you can run into... Ciao, Michael. From aspineux at gmail.com Thu May 24 00:37:42 2007 From: aspineux at gmail.com (Alain Spineux) Date: Thu, 24 May 2007 00:37:42 +0200 Subject: unicode value In-Reply-To: <4654B80E.3080208@stroeder.com> References: <71fe4e760705231016y24e8ca5ekcca2e6b37a4699f4@mail.gmail.com> <4654B80E.3080208@stroeder.com> Message-ID: <71fe4e760705231537g5ab3f519y9116f1357a8383d@mail.gmail.com> On 5/23/07, Michael Str?der wrote: > Alain Spineux wrote: > > Why does python-ldap not convert automatically any unicode string into > > UTF-8 before > > to call the raw function ? > > > > Is-it by design or just a lack of time ? > > Kind of a FAQ. Feel free to propose a patch with a good(!) solution. > > https://sourceforge.net/tracker/?func=detail&atid=352072&aid=616567&group_id=2072 > > Being the author of a schema-aware LDAP client based on python-ldap I > know in how many detail problems you can run into... They are two problems: - First, encode data when sending request to ldap server. Do you know an drawback to encode any unicode sting into utf-8 ? -Second, decode data coming back from the server. The only function to retrieve data is search(), right ? what about the use of this kind of request ? ldap_con.search_s(base_dn, ldap.SCOPE_BASE, filter, ['cn', 'mail', u'givenName', u'sn' ]) that way, python-lib know that attribute givenName and sn should be decoded into unicode string. Do you see any other problems ? > > Ciao, Michael. > -- -- Alain Spineux aspineux gmail com May the sources be with you From michael at stroeder.com Thu May 24 09:15:29 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 24 May 2007 09:15:29 +0200 Subject: unicode value In-Reply-To: <71fe4e760705231537g5ab3f519y9116f1357a8383d@mail.gmail.com> References: <71fe4e760705231016y24e8ca5ekcca2e6b37a4699f4@mail.gmail.com> <4654B80E.3080208@stroeder.com> <71fe4e760705231537g5ab3f519y9116f1357a8383d@mail.gmail.com> Message-ID: <46553B91.3000703@stroeder.com> Alain Spineux wrote: > On 5/23/07, Michael Str?der wrote: >> >> https://sourceforge.net/tracker/?func=detail&atid=352072&aid=616567&group_id=2072 > > - First, encode data when sending request to ldap server. > Do you know an drawback to encode any unicode sting into utf-8 ? Did you read my comment in the tracker item above? I repeat it here: "One cannot always assume UTF-8 encoded Unicode strings in attribute values. Think of attributes jpegPhoto, userCertificate, etc. Therefore there's no generic way to handle that at the API level without knowledge about the syntax defined in the LDAP schema. (Note that this has been debated to death on python-ldap-dev mailing list.)" > -Second, decode data coming back from the server. > The only function to retrieve data is search(), right ? Not necessarily. Think of LDAP extended operations, like whoami_s(). > what about the use of this kind of request ? > ldap_con.search_s(base_dn, ldap.SCOPE_BASE, filter, ['cn', 'mail', > u'givenName', u'sn' ]) > > that way, python-lib know that attribute givenName and sn should be > decoded into unicode string. This will be cumbersome. You will have to pass these attributes into method result() which in general has no knowledge about a particular request it's receiving results for. And I'll keep it like this because I still have the idea for implementing a connection pool with less thread locking. Also it's not only a question of Unicode or not. It's very simple to implement a small wrapper class sufficient for simple applications. But I'm against doing this in the general python-ldap API. Ciao, Michael. From aspineux at gmail.com Thu May 24 14:34:43 2007 From: aspineux at gmail.com (Alain Spineux) Date: Thu, 24 May 2007 14:34:43 +0200 Subject: unicode value In-Reply-To: <46553B91.3000703@stroeder.com> References: <71fe4e760705231016y24e8ca5ekcca2e6b37a4699f4@mail.gmail.com> <4654B80E.3080208@stroeder.com> <71fe4e760705231537g5ab3f519y9116f1357a8383d@mail.gmail.com> <46553B91.3000703@stroeder.com> Message-ID: <71fe4e760705240534y4dced9f2t8da849af81c23cef@mail.gmail.com> On 5/24/07, Michael Str?der wrote: > Alain Spineux wrote: > > On 5/23/07, Michael Str?der wrote: > >> > >> https://sourceforge.net/tracker/?func=detail&atid=352072&aid=616567&group_id=2072 > > > > - First, encode data when sending request to ldap server. > > Do you know an drawback to encode any unicode sting into utf-8 ? > > Did you read my comment in the tracker item above? I repeat it here: Yes I did ! > > "One cannot always assume UTF-8 encoded Unicode strings in > attribute values. Think of attributes jpegPhoto, When writing my ldap.search() request I know jpegPhoto is raw data and not a string ! This is why I will use 'jpegPhoto' and not u'jpegPhoto' in the attribute list. On the other hand, I will never use a unicode string for a jpegPhoto value in ldap.modify() or ldap.add(). > userCertificate, etc. Therefore there's no generic way to > handle that at the API level without knowledge about the > syntax defined in the LDAP schema. > (Note that this has been debated to death on python-ldap-dev > mailing list.)" > > > -Second, decode data coming back from the server. > > The only function to retrieve data is search(), right ? > > Not necessarily. Think of LDAP extended operations, like whoami_s(). > > > what about the use of this kind of request ? > > ldap_con.search_s(base_dn, ldap.SCOPE_BASE, filter, ['cn', 'mail', > > u'givenName', u'sn' ]) > > > > that way, python-lib know that attribute givenName and sn should be > > decoded into unicode string. > > This will be cumbersome. You will have to pass these attributes into > method result() which in general has no knowledge about a particular > request it's receiving results for. And I'll keep it like this because I Ops, I forgot the asynchronous side of ldap, but the msgid make the link between both the request and the result and a dictionary store in the ldapobject could store the unicode transcoding info used in the request. And then ldap.result(), could use these info to decode the value when user call it. > still have the idea for implementing a connection pool with less thread > locking. Also it's not only a question of Unicode or not. [OFF-TOPIC] You are speaking about thread, I used asynchat for 2 different projects. This could be an option for python-ldap > It's very simple to implement a small wrapper class sufficient for > simple applications. But I'm against doing this in the general > python-ldap API. Yes of course a wrapper around each function to convert input and output. Thanks for your advice. I'start writin a wrapper for search() and modify() now. I send you my results as soon a possible. Best regards. Alain -- Alain Spineux aspineux gmail com May the sources be with you -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Thu May 24 14:56:01 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 24 May 2007 14:56:01 +0200 Subject: unicode value In-Reply-To: <71fe4e760705240534y4dced9f2t8da849af81c23cef@mail.gmail.com> References: <71fe4e760705231016y24e8ca5ekcca2e6b37a4699f4@mail.gmail.com> <4654B80E.3080208@stroeder.com> <71fe4e760705231537g5ab3f519y9116f1357a8383d@mail.gmail.com> <46553B91.3000703@stroeder.com> <71fe4e760705240534y4dced9f2t8da849af81c23cef@mail.gmail.com> Message-ID: <46558B61.4010808@stroeder.com> Alain Spineux wrote: > > On 5/24/07, Michael Str?der wrote: >> >> "One cannot always assume UTF-8 encoded Unicode strings in >> attribute values. Think of attributes jpegPhoto, > > When writing my ldap.search() request I know jpegPhoto is raw data and > not a string ! > This is why I will use 'jpegPhoto' and not u'jpegPhoto' in the > attribute list. And how about specials like '*' and '+' in attrlist? >> > what about the use of this kind of request ? >> > ldap_con.search_s(base_dn, ldap.SCOPE_BASE, filter, ['cn', 'mail', >> > u'givenName', u'sn' ]) >> > >> > that way, python-lib know that attribute givenName and sn should be >> > decoded into unicode string. >> >> This will be cumbersome. You will have to pass these attributes into >> method result() which in general has no knowledge about a particular >> request it's receiving results for. And I'll keep it like this because I > > Ops, I forgot the asynchronous side of ldap, but the msgid make the link > between both > the request and the result and a dictionary store in the ldapobject > could store the > unicode transcoding info used in the request. And then ldap.result(), > could use these > info to decode the value when user call it. Yes, you could do this. But IMO it's cumbersome. > I'start writin a wrapper for search() and modify() now. > > I send you my results as soon a possible. I'm not too keen to incorporate Unicode patches in python-ldap's low-level API... Ciao, Michael. From aspineux at gmail.com Thu May 24 15:32:10 2007 From: aspineux at gmail.com (Alain Spineux) Date: Thu, 24 May 2007 15:32:10 +0200 Subject: unicode value In-Reply-To: <46558B61.4010808@stroeder.com> References: <71fe4e760705231016y24e8ca5ekcca2e6b37a4699f4@mail.gmail.com> <4654B80E.3080208@stroeder.com> <71fe4e760705231537g5ab3f519y9116f1357a8383d@mail.gmail.com> <46553B91.3000703@stroeder.com> <71fe4e760705240534y4dced9f2t8da849af81c23cef@mail.gmail.com> <46558B61.4010808@stroeder.com> Message-ID: <71fe4e760705240632j78dc4e53o5270ef2f50929ced@mail.gmail.com> On 5/24/07, Michael Str?der wrote: > > Alain Spineux wrote: > > > > On 5/24/07, Michael Str?der wrote: > >> > > And how about specials like '*' and '+' in attrlist? Thanks for showing me my ignorance. I was not knowing about * and + ! Easy, only named attributes will be converted! In this case maybe is it possible to use [ '*', u'givenName', u'sn' ] to convert only 'givenName' and 'sn' > > Ops, I forgot the asynchronous side of ldap, but the msgid make the link > > between both > > the request and the result and a dictionary store in the ldapobject > > could store the > > unicode transcoding info used in the request. And then ldap.result(), > > could use these > > info to decode the value when user call it. > > Yes, you could do this. But IMO it's cumbersome. YES and I hope you will integrate my patch in your mainstream source code :-) > I'start writin a wrapper for search() and modify() now. > > > > I send you my results as soon a possible. > > I'm not too keen to incorporate Unicode patches in python-ldap's > low-level API... not low-level Here is my work on progress class UnicodeLDAPObject(LDAPObject): expiration_delay=300 def __init__(self, uri, **kwargs): LDAPObject.__init__(self, uri, **kwargs) self.unicode_decoder={} self.unicode_decoder_expire=[] def search_ext(self,base,scope, **kwargs): # filterstr='(objectClass=*)',attrlist=None,attrsonly=0,serverctrls=None,clientctrls=None,timeout=-1,sizelimit=0 # convert filter try: kwargs['filter']=unicode2utf8(kwargs['filter']) except KeyError: pass # convert arglist and keep a copy of original values for later decoding try: attrlist=kwargs['attrlist'] kwargs['attrlist']=map(unicode2utf8(kwargs['attrlist'])) except KeyError: attrlist=None mesgid=LDAPObject.search_ext(self,base,scope, **kwargs) if attrlist: self.unicode_decoder[mesgid]=attrlist self.unicode_decoder_expire.append((mesgid, datetime.datetime.now()+datetime.timedelta(seconds=self.expiration_delay))) return mesgid def result3(self, **kwargs): # msgid=_ldap.RES_ANY,all=1,timeout=None): rtype, rdata, rmsgid, decoded_serverctrls=LDAPObject.result3(self, **kwargs) Alain -- Alain Spineux aspineux gmail com May the sources be with you -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Thu May 24 16:00:24 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 24 May 2007 16:00:24 +0200 Subject: unicode value In-Reply-To: <71fe4e760705240632j78dc4e53o5270ef2f50929ced@mail.gmail.com> References: <71fe4e760705231016y24e8ca5ekcca2e6b37a4699f4@mail.gmail.com> <4654B80E.3080208@stroeder.com> <71fe4e760705231537g5ab3f519y9116f1357a8383d@mail.gmail.com> <46553B91.3000703@stroeder.com> <71fe4e760705240534y4dced9f2t8da849af81c23cef@mail.gmail.com> <46558B61.4010808@stroeder.com> <71fe4e760705240632j78dc4e53o5270ef2f50929ced@mail.gmail.com> Message-ID: <46559A78.9000105@stroeder.com> Alain Spineux wrote: > > On 5/24/07, *Michael Str?der* > wrote: > > Alain Spineux wrote: > > > > On 5/24/07, Michael Str?der > wrote: > >> > > And how about specials like '*' and '+' in attrlist? > > Thanks for showing me my ignorance. I was not knowing about * and + ! > Easy, only named attributes will be converted! > In this case maybe is it possible to use [ '*', u'givenName', u'sn' ] > to convert only 'givenName' and 'sn' But then you will not gain much! Still the application has to know which attributes have to be converted. => It's not worth hiding the conversion within python-ldap. > > I'start writin a wrapper for search() and modify() now. > > > > I send you my results as soon a possible. > > I'm not too keen to incorporate Unicode patches in python-ldap's > low-level API... > > not low-level > > Here is my work on progress > > class UnicodeLDAPObject(LDAPObject): Sorry, I consider ldap.ldapobject to be low-level. The only clean solution would be something involving LDAP schema processing! Ciao, Michael. From aspineux at gmail.com Thu May 24 16:50:14 2007 From: aspineux at gmail.com (Alain Spineux) Date: Thu, 24 May 2007 16:50:14 +0200 Subject: unicode value In-Reply-To: <46559A78.9000105@stroeder.com> References: <71fe4e760705231016y24e8ca5ekcca2e6b37a4699f4@mail.gmail.com> <4654B80E.3080208@stroeder.com> <71fe4e760705231537g5ab3f519y9116f1357a8383d@mail.gmail.com> <46553B91.3000703@stroeder.com> <71fe4e760705240534y4dced9f2t8da849af81c23cef@mail.gmail.com> <46558B61.4010808@stroeder.com> <71fe4e760705240632j78dc4e53o5270ef2f50929ced@mail.gmail.com> <46559A78.9000105@stroeder.com> Message-ID: <71fe4e760705240750r3daa768fhd7256289d1432d81@mail.gmail.com> On 5/24/07, Michael Str?der wrote: > > Alain Spineux wrote: > > > > On 5/24/07, *Michael Str?der* > > wrote: > > > > Thanks for showing me my ignorance. I was not knowing about * and + ! > > Easy, only named attributes will be converted! > > In this case maybe is it possible to use [ '*', u'givenName', u'sn' ] > > to convert only 'givenName' and 'sn' > > But then you will not gain much! Still the application has to know which > attributes have to be converted. => It's not worth hiding the conversion > within python-ldap. I don't spend too much then I dont't expect too much too :-) Are you using often '+' and '*' (in real application, not ldap browser, nor editor tools) ? And that way, user keep control with explicit conversion. > > > class UnicodeLDAPObject(LDAPObject): > > Sorry, I consider ldap.ldapobject to be low-level. :-( The only clean solution would be something involving LDAP schema processing! Yes but what about unknown field type ? Ciao, Michael. > Your remarks help me, don't hesitate to share your feeling. -- -- Alain Spineux aspineux gmail com May the sources be with you -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Thu May 24 18:56:09 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 24 May 2007 18:56:09 +0200 Subject: unicode value In-Reply-To: <71fe4e760705240750r3daa768fhd7256289d1432d81@mail.gmail.com> References: <71fe4e760705231016y24e8ca5ekcca2e6b37a4699f4@mail.gmail.com> <4654B80E.3080208@stroeder.com> <71fe4e760705231537g5ab3f519y9116f1357a8383d@mail.gmail.com> <46553B91.3000703@stroeder.com> <71fe4e760705240534y4dced9f2t8da849af81c23cef@mail.gmail.com> <46558B61.4010808@stroeder.com> <71fe4e760705240632j78dc4e53o5270ef2f50929ced@mail.gmail.com> <46559A78.9000105@stroeder.com> <71fe4e760705240750r3daa768fhd7256289d1432d81@mail.gmail.com> Message-ID: <4655C3A9.5050803@stroeder.com> Alain Spineux wrote: > > Are you using often '+' and '*' (in real application, not ldap browser, > nor editor tools) ? In small scripts I'm explicitly requesting certain attribute types. Hmm, not sure about some directory sync tools I wrote for customers which have kind of a generic processing and low-level classes create different entry objects. > And that way, user keep control with explicit conversion. But I suspect that most programmers use '*' in their home-grown scripts. > > The only clean solution would be something involving LDAP schema > > processing! > > Yes but what about unknown field type ? If you really want to dive into this look in directory pylib/w2lapp/schema/ of web2ldap's source. It works for me but I did not consider this whole framework mature enough to be incorporated into python-ldap. Ciao, Michael. From aspineux at gmail.com Thu May 24 21:16:26 2007 From: aspineux at gmail.com (Alain Spineux) Date: Thu, 24 May 2007 21:16:26 +0200 Subject: unicode value In-Reply-To: <4655C3A9.5050803@stroeder.com> References: <71fe4e760705231016y24e8ca5ekcca2e6b37a4699f4@mail.gmail.com> <4654B80E.3080208@stroeder.com> <71fe4e760705231537g5ab3f519y9116f1357a8383d@mail.gmail.com> <46553B91.3000703@stroeder.com> <71fe4e760705240534y4dced9f2t8da849af81c23cef@mail.gmail.com> <46558B61.4010808@stroeder.com> <71fe4e760705240632j78dc4e53o5270ef2f50929ced@mail.gmail.com> <46559A78.9000105@stroeder.com> <71fe4e760705240750r3daa768fhd7256289d1432d81@mail.gmail.com> <4655C3A9.5050803@stroeder.com> Message-ID: <71fe4e760705241216n52bf6848r9fa0e70512f8fbc9@mail.gmail.com> On 5/24/07, Michael Str?der wrote: > > Alain Spineux wrote: > > > > Yes but what about unknown field type ? > > If you really want to dive into this look in directory > pylib/w2lapp/schema/ of web2ldap's source. It works for me but I did not > consider this whole framework mature enough to be incorporated into > python-ldap. I dont want to look at the schema: Here are the sources and the results. I use your more appropriate name for unicode testing :-) #!/usr/bin/env python2.4 import sys, os, time import ldap, ldapurl, ldap.modlist import types import datetime host='localhost' port=389 base_dn='dc=asxnet,dc=loc' if True: who='cn=manager,cn=internal,dc=asxnet,dc=loc' cred=''********' else: who='cn=nobody,cn=internal,dc=asxnet,dc=loc' cred='iMmTWz5pJ+lwY7i6M/BU61ngo1aBLyqQhRrrKbEc' def unicode2utf8(st): """Convert unicode (and only unicode) string into utf-8 raw string as expected by ldap""" if isinstance(st, types.UnicodeType): return st.encode('utf-8') else: return st def utf82unicode(st): """encode st into utf-8""" return st.decode('utf-8') def encode_modlist(modlist, no_op): """encode ldap modlist structure set no_op=True for Tuple of kind (int,str,[str,...]) and False for (str, [str,...]) """ for i, mod in enumerate(modlist): if no_op: attr_name, attr_values=mod else: op, attr_name, attr_values=mod attr_name=unicode2utf8(attr_name) if isinstance(attr_values, (types.ListType, types.TupleType)): attr_values=map(unicode2utf8, attr_values) else: attr_values=unicode2utf8(attr_values) if no_op: modlist[i]=(attr_name, attr_values) else: modlist[i]=(op, attr_name, attr_values) return modlist class UnicodeLDAPObject(ldap.ldapobject.LDAPObject): expiration_delay=300 def __init__(self, uri, **kwargs): ldap.ldapobject.LDAPObject.__init__(self, uri, **kwargs) self.unicode_decoder={} # (msgid, expiration, decoder_data) # I use an expiration time to avoid the list to become to big when the # server don't answere any request def search_ext(self,base,scope, filterstr, attrlist, *args, **kwargs): # base,scope, filterstr='(objectClass=*)',attrlist=None,attrsonly=0,serverctrls=None,clientctrls=None,timeout=-1,sizelimit=0 # convert filter filterstr=unicode2utf8(filterstr) # convert arglist and keep a copy of original values for later decoding u_attrlist=attrlist decoder={} if u_attrlist!=None: attrlist=[] for attr in u_attrlist: if isinstance(attr, types.UnicodeType): attr=attr.encode('utf-8') # print 'ATTR', attr decoder[attr]=True attrlist.append(attr) msgid=ldap.ldapobject.LDAPObject.search_ext(self,base,scope, filterstr, attrlist, *args, **kwargs) if decoder: timeout=kwargs.get('timeout', None) if timeout==None or timeout<=0: timeout=self.expiration_delay self.unicode_decoder[msgid]=(msgid, datetime.datetime.now()+datetime.timedelta(seconds=timeout), decoder) return msgid def result3(self, *args, **kwargs): # kwargs=(self, msgid=_ldap.RES_ANY,all=1,timeout=None): rtype, rdata, rmsgid, decoded_serverctrls= ldap.ldapobject.LDAPObject.result3(self, *args, **kwargs) if self.unicode_decoder.has_key(rmsgid): msgid, expire, decoder=self.unicode_decoder[rmsgid] if rtype not in [ ldap.RES_SEARCH_ENTRY, ldap.RES_SEARCH_REFERENCE ]: # this was the last result del self.unicode_decoder[rmsgid] else: # reset the timeout timeout=kwargs.get('timeout', None) if timeout==None or timeout<=0: timeout=self.expiration_delay self.unicode_decoder[msgid]=(msgid, datetime.datetime.now()+datetime.timedelta(seconds=timeout), decoder) # now decode the result if rdata: if rtype in [ldap.RES_SEARCH_ENTRY, ldap.RES_SEARCH_REFERENCE, ldap.RES_SEARCH_RESULT]: # FIXME: I dont know what is a RES_SEARCH_REFERENCE rdata_u=[] for i, (dn, attrs) in enumerate(rdata): # FIXME: should I handle the 'dn' the same way if decoder.has_key('dn'): dn=utf82unicode(dn) for key in attrs.keys(): if decoder.has_key(key): attrs[key]=map(utf82unicode, attrs[key]) # print '\tITEM=', dn, attrs rdata[i]=(dn, attrs) else: # no decoder for this => nothing to decode pass # remove other expired decoder info now=datetime.datetime.now() for msgid in self.unicode_decoder.keys(): if self.unicode_decoder[rmsgid][1] From ahasenack at terra.com.br Mon May 28 15:08:20 2007 From: ahasenack at terra.com.br (Andreas Hasenack) Date: Mon, 28 May 2007 10:08:20 -0300 Subject: controls and BER encoding of its values Message-ID: <20070528130819.GC3622@mandriva.com.br> Hi, last Friday I played a bit with controls in python-ldap. I was trying to get the matched-values control (LDAP_CONTROL_VALUESRETURNFILTER) to work. It seems I have to manually do the BER encoding of the values. I googled for some modules and pyasn1 seems to be the most complete one, but I would have to basically write classes for the whole LDAP spec :( This mailing list had some discussion about this previously, and some other names popped up, like pysnmp and pisces. So, what are you guys using for LDAP BER encoding in python nowadays? From michael at stroeder.com Mon May 28 20:07:09 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 28 May 2007 20:07:09 +0200 Subject: controls and BER encoding of its values In-Reply-To: <20070528130819.GC3622@mandriva.com.br> References: <20070528130819.GC3622@mandriva.com.br> Message-ID: <465B1A4D.60409@stroeder.com> Andreas Hasenack wrote: > > last Friday I played a bit with controls in python-ldap. I was trying to > get the matched-values control (LDAP_CONTROL_VALUESRETURNFILTER) to > work. Feel free to contribute your results. > It seems I have to manually do the BER encoding of the values. I googled > for some modules and pyasn1 seems to be the most complete one, but I > would have to basically write classes for the whole LDAP spec :( You can use pyasn1 for just creating the BER en-/decoding the control values. Please look into Lib/ldap/controls.py to get the idea how you can implement the methods for encoding and decoding in sub-classes of ldap.controls.LDAPControl. > This mailing list had some discussion about this previously, and some > other names popped up, like pysnmp and pisces. pisces is pretty much dead although I'm still using it in web2ldap for certificate decoding. pyasn1 was extracted from pysnmp - same author. Ciao, Michael. From aspineux at gmail.com Tue May 29 16:29:46 2007 From: aspineux at gmail.com (Alain Spineux) Date: Tue, 29 May 2007 16:29:46 +0200 Subject: unicode value In-Reply-To: <71fe4e760705241216n52bf6848r9fa0e70512f8fbc9@mail.gmail.com> References: <71fe4e760705231016y24e8ca5ekcca2e6b37a4699f4@mail.gmail.com> <71fe4e760705231537g5ab3f519y9116f1357a8383d@mail.gmail.com> <46553B91.3000703@stroeder.com> <71fe4e760705240534y4dced9f2t8da849af81c23cef@mail.gmail.com> <46558B61.4010808@stroeder.com> <71fe4e760705240632j78dc4e53o5270ef2f50929ced@mail.gmail.com> <46559A78.9000105@stroeder.com> <71fe4e760705240750r3daa768fhd7256289d1432d81@mail.gmail.com> <4655C3A9.5050803@stroeder.com> <71fe4e760705241216n52bf6848r9fa0e70512f8fbc9@mail.gmail.com> Message-ID: <71fe4e760705290729rd90c462h458d718aa748ab29@mail.gmail.com> Hi Michael When investigating about python and unicode, I read somewhere (in a PEP I thing) that python functions should accept and manage unicode string as well as normal string.Of course if these strings could contains user readable characters. This is not the case for python-ldap functions. Sometime when calling python-ldap, we don't know well the origin ( a function is not suposed to know its caller :-) of the arguments we are using : user input, web interface, mysql database, ldap result, web form, literal, text file, text parsing... some are unicode, other not. I thing python-ldap function must accept unicode arguments. As we discussed at length previously, the decoding of the result is less easy because, the library cannot guess alone the meaning of these values. I'm not supporting the idea of downloading and use the ldap schema. I cannot imaging a connection less application like a web application doing that at any request! Or keeping a cache for the schema ... Anyway I see 2 solutions 1. Let result() return non unicode strings. _HERE_ The user know all returned strings are normal strings utf-8 encoded and he can do the encoding himself. A helper function doing the job for the result structure should be welcome. 2. Do the conversion regarding the info provided in the query, as my source sample does. I answer now some of your previous comment: > > In this case maybe is it possible to use [ '*', u'givenName', u'sn' ] > > to convert only 'givenName' and 'sn' > But then you will not gain much! Still the application has to know which > attributes have to be converted. => It's not worth hiding the conversion > within python-ldap. I don't really hide the conversion, because the user has to request it using unicode field name. And second, I do more work: I keep a link between the msgid and the request to know with fields I have to convert and also destroy the link when unneeded anymore. > The only clean solution would be something involving LDAP schema processing! You know better than me how costly it is, in developing time, and its overhead for CPU and network load. Do you really consider to add the schema processing for unicode integration in the future? Or are you hoping that someone will send you a patch :-) ? I know you were not very exited by my ideas, anyway the unicode support for argument encoding is important. (this is my opinion) Feel free to suggest some cosmetic changes: function name, class name, the way I wrap your base class ..... Keep in mind, none of my code break compatibility with existing application. Best regards. On 5/24/07, Alain Spineux wrote: > > > > On 5/24/07, Michael Str?der wrote: > > > > Alain Spineux wrote: > > > > > > Yes but what about unknown field type ? > > > > If you really want to dive into this look in directory > > pylib/w2lapp/schema/ of web2ldap's source. It works for me but I did not > > consider this whole framework mature enough to be incorporated into > > python-ldap. > > > I dont want to look at the schema: > > Here are the sources and the results. > I use your more appropriate name for unicode testing :-) > > > #!/usr/bin/env python2.4 > > import sys, os, time > import ldap, ldapurl, ldap.modlist > import types > import datetime > > host='localhost' > port=389 > base_dn='dc=asxnet,dc=loc' > > if True: > who='cn=manager,cn=internal,dc=asxnet,dc=loc' > cred=''********' > else: > who='cn=nobody,cn=internal,dc=asxnet,dc=loc' > cred='iMmTWz5pJ+lwY7i6M/BU61ngo1aBLyqQhRrrKbEc' > > > def unicode2utf8(st): > """Convert unicode (and only unicode) string into utf-8 raw string as > expected by ldap""" > > if isinstance(st, types.UnicodeType): > return st.encode('utf-8') > else: > return st > > def utf82unicode(st): > """encode st into utf-8""" > return st.decode('utf-8') > > > def encode_modlist(modlist, no_op): > """encode ldap modlist structure > set no_op=True for Tuple of kind (int,str,[str,...]) > and False for (str, [str,...]) > """ > > for i, mod in enumerate(modlist): > if no_op: > attr_name, attr_values=mod > else: > op, attr_name, attr_values=mod > > attr_name=unicode2utf8(attr_name) > if isinstance(attr_values, ( types.ListType, types.TupleType)): > attr_values=map(unicode2utf8, attr_values) > else: > attr_values=unicode2utf8(attr_values) > if no_op: > modlist[i]=(attr_name, attr_values) > else: > modlist[i]=(op, attr_name, attr_values) > > return modlist > > class UnicodeLDAPObject(ldap.ldapobject.LDAPObject): > > expiration_delay=300 > > def __init__(self, uri, **kwargs): > ldap.ldapobject.LDAPObject.__init__(self, uri, **kwargs) > self.unicode_decoder={} # (msgid, expiration, decoder_data) > # I use an expiration time to avoid the list to become to big when > the > # server don't answere any request > > def search_ext(self,base,scope, filterstr, attrlist, *args, **kwargs): > # base,scope, > filterstr='(objectClass=*)',attrlist=None,attrsonly=0,serverctrls=None,clientctrls=None,timeout=-1,sizelimit=0 > > > # convert filter > filterstr=unicode2utf8(filterstr) > > # convert arglist and keep a copy of original values for later > decoding > > u_attrlist=attrlist > decoder={} > if u_attrlist!=None: > attrlist=[] > for attr in u_attrlist: > if isinstance(attr, types.UnicodeType): > attr=attr.encode('utf-8') > # print 'ATTR', attr > decoder[attr]=True > attrlist.append(attr) > > msgid=ldap.ldapobject.LDAPObject.search_ext(self,base,scope, > filterstr, attrlist, *args, **kwargs) > > if decoder: > timeout=kwargs.get('timeout', None) > if timeout==None or timeout<=0: > timeout=self.expiration_delay > self.unicode_decoder[msgid]=(msgid, datetime.datetime.now()+datetime.timedelta(seconds=timeout), decoder) > return msgid > > def result3(self, *args, **kwargs): > # kwargs=(self, msgid=_ldap.RES_ANY,all=1,timeout=None): > rtype, rdata, rmsgid, decoded_serverctrls= > ldap.ldapobject.LDAPObject.result3(self, *args, **kwargs) > > if self.unicode_decoder.has_key(rmsgid): > msgid, expire, decoder=self.unicode_decoder[rmsgid] > if rtype not in [ ldap.RES_SEARCH_ENTRY, > ldap.RES_SEARCH_REFERENCE ]: > # this was the last result > del self.unicode_decoder[rmsgid] > else: > # reset the timeout > timeout= kwargs.get('timeout', None) > if timeout==None or timeout<=0: > timeout=self.expiration_delay > self.unicode_decoder[msgid]=(msgid, datetime.datetime.now()+datetime.timedelta(seconds=timeout), > decoder) > > # now decode the result > if rdata: > if rtype in [ldap.RES_SEARCH_ENTRY, > ldap.RES_SEARCH_REFERENCE, ldap.RES_SEARCH_RESULT]: > # FIXME: I dont know what is a RES_SEARCH_REFERENCE > rdata_u=[] > for i, (dn, attrs) in enumerate(rdata): > # FIXME: should I handle the 'dn' the same way > if decoder.has_key ('dn'): > dn=utf82unicode(dn) > for key in attrs.keys(): > if decoder.has_key(key): > attrs[key]=map(utf82unicode, attrs[key]) > # print '\tITEM=', dn, attrs > rdata[i]=(dn, attrs) > > else: > # no decoder for this => nothing to decode > pass > > # remove other expired decoder info > now=datetime.datetime.now() > for msgid in self.unicode_decoder.keys(): > if self.unicode_decoder[rmsgid][1] del self.unicode_decoder[rmsgid] > > return rtype, rdata, rmsgid, decoded_serverctrls > > def add_ext(self, dn, modlist, *args, **kwargs): > # args=(self,dn,modlist,serverctrls=None,clientctrls=None) > dn=unicode2utf8(dn) > # print 'MODLIST', modlist > modlist=encode_modlist(modlist, True) > # print 'MODLIST unicode', modlist > return ldap.ldapobject.LDAPObject.add_ext (self, dn, modlist, > *args, **kwargs) > > def modify_ext(self, dn, modlist, *args, **kwargs): > # args=(self,dn,modlist,serverctrls=None,clientctrls=None) > dn=unicode2utf8(dn) > # print 'MODLIST', modlist > modlist=encode_modlist(modlist, False) > # print 'MODLIST unicode', modlist > return ldap.ldapobject.LDAPObject.modify_ext(self, dn, modlist, > *args, **kwargs) > > def delete_ext(self, dn, *args, **kwargs): > # args=(self,dn,serverctrls=None,clientctrls=None) > dn=unicode2utf8(dn) > return ldap.ldapobject.LDAPObject.delete_ext(self, dn, *args, > **kwargs) > > > > def print_ldap_result(ldap_result): > for dn, item in ldap_result: > print 'DN=', repr(dn) > for k, v in item.iteritems(): > print '\t%s: %s' % (k, repr(v)) > print > > ldap_url=ldapurl.LDAPUrl ('ldap://%s:%d/%s' % (host, port, base_dn)) > ldap_url.applyDefaults({ > 'who': who, > 'cred' : cred, }) > #l=ldap.ldapobject.LDAPObject(ldap_url.initializeUrl()) > l=UnicodeLDAPObject(ldap_url.initializeUrl()) > l.simple_bind_s(ldap_url.who, ldap_url.cred) > print 'Connected as', l.whoami_s() > > > first_name='Michael' > first_name2=u'Micha\xebl' > last_name=u'Str\xf6der' > email=' michael at stroeder.com' > street=u'Hauptstra\xe1e' > country='Germany' > > cn='%s %s' %(first_name, last_name) > dn='cn=%s,%s' %(cn, base_dn) > info={ > u'cn' : (cn, ), > 'mail' : (email, ), > 'objectClass' : ('top', 'inetOrgPerson', 'kolabInetOrgPerson',), > u'sn' : (last_name, ), > u'givenName' : (first_name, ), > u'street': (street, ), > 'c': (country, ), > 'telephoneNumber': '+49 1111111111', > } > > ldap_result=l.search_s(base_dn, ldap.SCOPE_ONELEVEL , '(cn=%s)' % (cn,) , > info.keys()) > if ldap_result: > print '== Found' > print_ldap_result(ldap_result) > l.delete_s(dn) > print '== Deleted' > > l.add_s(dn, ldap.modlist.addModlist (info)) > print '== Created' > ldap_result=l.search_s(base_dn, ldap.SCOPE_ONELEVEL, '(cn=%s)' % (cn,) , > info.keys()) > print_ldap_result(ldap_result) > > l.modify_s(dn, [(ldap.MOD_REPLACE, u'givenName', first_name2), > (ldap.MOD_ADD, 'telephoneNumber', ( '+49 1234567890', )), > ]) > > print '==Modified' > ldap_result=l.search_s(base_dn, ldap.SCOPE_ONELEVEL, '(cn=%s)' % (cn,) , > info.keys()) > print_ldap_result(ldap_result) > > print '==Display once more' > ldap_result=l.search_s(base_dn, ldap.SCOPE_ONELEVEL, '(cn=%s)' % (cn,) , > ['*', '+', u'dn', u'givenName', u'creatorsName'] ) > print_ldap_result(ldap_result) > > > > ============= > > > Connected as dn:cn=manager,cn=internal,dc=asxnet,dc=loc > == Found > DN= 'cn=Michael Str\xc3\xb6der,dc=asxnet,dc=loc' > telephoneNumber: ['+49 1111111111', '+49 1234567890'] > c: ['Germany'] > cn: [u'Michael Str\xf6der'] > objectClass: ['top', 'inetOrgPerson', 'kolabInetOrgPerson'] > street: [u'Hauptstra\xe1e'] > sn: [u'Str\xf6der'] > mail: ['michael at stroeder.com'] > givenName: [u'Micha\xebl'] > > == Deleted > == Created > DN= 'cn=Michael Str\xc3\xb6der,dc=asxnet,dc=loc' > telephoneNumber: ['+49 1111111111'] > c: ['Germany'] > cn: [u'Michael Str\xf6der'] > objectClass: ['top', 'inetOrgPerson', 'kolabInetOrgPerson'] > street: [u'Hauptstra\xe1e'] > sn: [u'Str\xf6der'] > mail: ['michael at stroeder.com'] > givenName: [u'Michael'] > > ==Modified > DN= 'cn=Michael Str\xc3\xb6der,dc=asxnet,dc=loc' > telephoneNumber: ['+49 1111111111', '+49 1234567890'] > c: ['Germany'] > cn: [u'Michael Str\xf6der'] > objectClass: ['top', 'inetOrgPerson', 'kolabInetOrgPerson'] > street: [u'Hauptstra\xe1e'] > sn: [u'Str\xf6der'] > mail: [' michael at stroeder.com'] > givenName: [u'Micha\xebl'] > > ==Display more > DN= 'cn=Michael Str\xc3\xb6der,dc=asxnet,dc=loc' > telephoneNumber: ['+49 1111111111', '+49 1234567890'] > c: ['Germany'] > cn: [u'Michael Str\xf6der'] > objectClass: ['top', 'inetOrgPerson', 'kolabInetOrgPerson'] > street: [u'Hauptstra\xe1e'] > sn: [u'Str\xf6der'] > mail: ['michael at stroeder.com'] > givenName: [u'Micha\xebl'] > > ==Display once more > DN= u'cn=Michael Str\xf6der,dc=asxnet,dc=loc' > telephoneNumber: ['+49 1111111111', '+49 1234567890'] > c: ['Germany'] > entryCSN: ['20070524191126Z#000002#00#000000'] > cn: ['Michael Str\xc3\xb6der'] > entryDN: ['cn=Michael Str\xc3\xb6der,dc=asxnet,dc=loc'] > createTimestamp: ['20070524191126Z'] > objectClass: ['top', 'inetOrgPerson', 'kolabInetOrgPerson'] > creatorsName: [u'cn=manager,cn=internal,dc=asxnet,dc=loc'] > entryUUID: ['5099e82e-9e76-102b-830b-0da78c7bd35e'] > hasSubordinates: ['FALSE'] > modifiersName: ['cn=manager,cn=internal,dc=asxnet,dc=loc'] > street: ['Hauptstra\xc3\xa1e'] > sn: ['Str\xc3\xb6der'] > structuralObjectClass: ['inetOrgPerson'] > subschemaSubentry: ['cn=Subschema'] > mail: [' michael at stroeder.com'] > givenName: [u'Micha\xebl'] > modifyTimestamp: ['20070524191126Z'] > > > > > > -- > -- > Alain Spineux > aspineux gmail com > May the sources be with you > -- -- Alain Spineux aspineux gmail com May the sources be with you -------------- next part -------------- An HTML attachment was scrubbed... URL: From aspineux at gmail.com Thu May 31 14:25:55 2007 From: aspineux at gmail.com (Alain Spineux) Date: Thu, 31 May 2007 14:25:55 +0200 Subject: unicode value In-Reply-To: <71fe4e760705290729rd90c462h458d718aa748ab29@mail.gmail.com> References: <71fe4e760705231016y24e8ca5ekcca2e6b37a4699f4@mail.gmail.com> <46553B91.3000703@stroeder.com> <71fe4e760705240534y4dced9f2t8da849af81c23cef@mail.gmail.com> <46558B61.4010808@stroeder.com> <71fe4e760705240632j78dc4e53o5270ef2f50929ced@mail.gmail.com> <46559A78.9000105@stroeder.com> <71fe4e760705240750r3daa768fhd7256289d1432d81@mail.gmail.com> <4655C3A9.5050803@stroeder.com> <71fe4e760705241216n52bf6848r9fa0e70512f8fbc9@mail.gmail.com> <71fe4e760705290729rd90c462h458d718aa748ab29@mail.gmail.com> Message-ID: <71fe4e760705310525k300aaf7eh3f0b43e11c699519@mail.gmail.com> Hi I changed my code to make it more modular. class UnicodeLDAPInterface: ldapbaseclass=None .... my code goes HERE class UnicodeLDAPObject(UnicodeLDAPInterface, LDAPObject): ldapbaseclass=LDAPObject class UnicodeReconnectLDAPObject(UnicodeLDAPInterface, ReconnectLDAPObject): ldapbaseclass=ReconnectLDAPObject Here is the full code #!/usr/bin/env python2.4 import types, datetime import ldap, ldapurl, ldap.modlist from ldap.ldapobject import LDAPObject from ldap.ldapobject import ReconnectLDAPObject def unicode2utf8(st): """Convert unicode (and only unicode) string into utf-8 raw string as expected by ldap""" if isinstance(st, types.UnicodeType): return st.encode('utf-8') else: return st def utf82unicode(st): """encode st into utf-8""" return st.decode('utf-8') def encode_modlist(modlist, no_op): """encode ldap modlist structure set no_op=True for Tuple of kind (int,str,[str,...]) and False for (str, [str,...]) """ for i, mod in enumerate(modlist): if no_op: attr_name, attr_values=mod else: op, attr_name, attr_values=mod attr_name=unicode2utf8(attr_name) if isinstance(attr_values, (types.ListType, types.TupleType)): attr_values=map(unicode2utf8, attr_values) else: attr_values=unicode2utf8(attr_values) if no_op: modlist[i]=(attr_name, attr_values) else: modlist[i]=(op, attr_name, attr_values) return modlist def _print_ldap_result(ldap_result): for dn, item in ldap_result: print 'DN=', repr(dn) for k, v in item.iteritems(): print '\t%s: %s' % (k, repr(v)) print class UnicodeLDAPInterface: ldapbaseclass=None decoder_expiration_delay=300 # the expiration delay for an object in self.unicode_decoder def __init__(self, uri, **kwargs): self.ldapbaseclass.__init__(self, uri, **kwargs) self.unicode_decoder={} # { (msgid, expiration, decoder_data) ... } # I use an expiration time to avoid the list to become to big when the # server don't answere some requests def _set_unicode_decoder(self, msgid, value): """protect unicode_decoder against multi-threading update or add the decoder """ self._ldap_object_lock.acquire() try: self.unicode_decoder[msgid]=value finally: self._ldap_object_lock.release() def _remove_unicode_decoder(self, msgid): """protect unicode_decoder against multi-threading remove the decoder """ self._ldap_object_lock.acquire() try: try: del self.unicode_decoder[msgid] except: # ignore any errors pass finally: self._ldap_object_lock.release() def _get_unicode_decoder(self, msgid): """protect unicode_decoder against multi-threading read the decoder info for msgid """ self._ldap_object_lock.acquire() try: return self.unicode_decoder[msgid] finally: self._ldap_object_lock.release() def _expire_unicode_decoder(self): """cleanup any expired decoder""" self._ldap_object_lock.acquire() now=datetime.datetime.now() for msgid in self.unicode_decoder.keys(): if self.unicode_decoder[msgid][1] nothing to decode else: if rtype not in [ ldap.RES_SEARCH_ENTRY, ldap.RES_SEARCH_REFERENCE ]: # this was the last result self._remove_unicode_decoder(rmsgid) else: # reset the timeout timeout=kwargs.get('timeout', None) if timeout==None or timeout<=0: timeout=self.expiration_delay self._set_unicode_decoder(msgid, (msgid, datetime.datetime.now()+datetime.timedelta(seconds=timeout), decoder)) # now decode the result if rdata: if rtype in [ldap.RES_SEARCH_ENTRY, ldap.RES_SEARCH_REFERENCE, ldap.RES_SEARCH_RESULT]: # FIXME: I dont know what is a RES_SEARCH_REFERENCE rdata_u=[] for i, (dn, attrs) in enumerate(rdata): # FIXME: should I handle the 'dn' the same way if decoder.has_key('dn'): dn=utf82unicode(dn) for key in attrs.keys(): if decoder.has_key(key): attrs[key]=map(utf82unicode, attrs[key]) # print '\tITEM=', dn, attrs rdata[i]=(dn, attrs) self._expire_unicode_decoder() return rtype, rdata, rmsgid, decoded_serverctrls def add_ext(self, dn, modlist, *args, **kwargs): # args=(self,dn,modlist,serverctrls=None,clientctrls=None) dn=unicode2utf8(dn) # print 'MODLIST', modlist modlist=encode_modlist(modlist, True) # print 'MODLIST unicode', modlist return self.ldapbaseclass.add_ext(self, dn, modlist, *args, **kwargs) def modify_ext(self, dn, modlist, *args, **kwargs): # args=(self,dn,modlist,serverctrls=None,clientctrls=None) dn=unicode2utf8(dn) # print 'MODLIST', modlist modlist=encode_modlist(modlist, False) # print 'MODLIST unicode', modlist return self.ldapbaseclass.modify_ext(self, dn, modlist, *args, **kwargs) def delete_ext(self, dn, *args, **kwargs): # args=(self,dn,serverctrls=None,clientctrls=None) dn=unicode2utf8(dn) return self.ldapbaseclass.delete_ext(self, dn, *args, **kwargs) def abandon_ext(self, msgid, *args, **kwargs): # args=(self,msgid,serverctrls=None,clientctrls=None) result=self.ldapbaseclass.abandon_ext(self, msgid, *args, **kwargs) self._remove_unicode_decoder(msgid) return result def cancel_ext(self, cancelid, *args, **kwargs): # args=(self,msgid,serverctrls=None,clientctrls=None) result=self.ldapbaseclass.cancel_ext(self, cancelid, *args, **kwargs) self._remove_unicode_decoder(cancelid) return result class UnicodeLDAPObject(UnicodeLDAPInterface, LDAPObject): ldapbaseclass=LDAPObject class UnicodeReconnectLDAPObject(UnicodeLDAPInterface, ReconnectLDAPObject): ldapbaseclass=ReconnectLDAPObject if __name__=='__main__': import sys, os, time host='localhost' port=389 base_dn='dc=asxnet,dc=loc' if True: who='cn=manager,cn=internal,dc=asxnet,dc=loc' cred='********' else: who='cn=nobody,cn=internal,dc=asxnet,dc=loc' cred='iMmTWz5pJ+lwY7i6M/BU61ngo1aBLyqQhRrrKbEc' ldap_url=ldapurl.LDAPUrl('ldap://%s:%d/%s' % (host, port, base_dn)) ldap_url.applyDefaults({ 'who': who, 'cred' : cred, }) print ldap_url #l=LDAPObject(ldap_url.initializeUrl()) #l=UnicodeLDAPObject(ldap_url.initializeUrl()) l=UnicodeReconnectLDAPObject(ldap_url.initializeUrl()) l.simple_bind_s(ldap_url.who, ldap_url.cred) print 'Connected as', l.whoami_s() first_name='Michael' first_name2=u'Micha\xebl' last_name=u'Str\xf6der' email='michael at stroeder.com' street=u'Hauptstra\xe1e' country='Germany' cn='%s %s' %(first_name, last_name) dn='cn=%s,%s' %(cn, base_dn) info={ u'cn' : (cn, ), 'mail' : (email, ), 'objectClass' : ('top', 'inetOrgPerson', 'kolabInetOrgPerson',), u'sn' : (last_name, ), u'givenName' : (first_name, ), u'street': (street, ), 'c': (country, ), 'telephoneNumber': '+49 1111111111', } ldap_result=l.search_s(base_dn, ldap.SCOPE_ONELEVEL, '(cn=%s)' % (cn,) , info.keys()) if ldap_result: print '== Found' _print_ldap_result(ldap_result) l.delete_s(dn) print '== Deleted' l.add_s(dn, ldap.modlist.addModlist(info)) print '== Created' ldap_result=l.search_s(base_dn, ldap.SCOPE_ONELEVEL, '(cn=%s)' % (cn,) , info.keys()) _print_ldap_result(ldap_result) l.modify_s(dn, [(ldap.MOD_REPLACE, u'givenName', first_name2), (ldap.MOD_ADD, 'telephoneNumber', ( '+49 1234567890', )), ]) print '==Modified' ldap_result=l.search_s(base_dn, ldap.SCOPE_ONELEVEL, '(cn=%s)' % (cn,) , info.keys()) _print_ldap_result(ldap_result) print '==Display once more' ldap_result=l.search_s(base_dn, ldap.SCOPE_ONELEVEL, '(cn=%s)' % (cn,) , ['*', '+', u'dn', u'givenName', u'creatorsName'] ) _print_ldap_result(ldap_result) On 5/29/07, Alain Spineux wrote: > > Hi Michael > > When investigating about python and unicode, I read somewhere (in a PEP > I thing) that python functions should accept and manage unicode string > as well as normal string.Of course if these strings could contains user > readable characters. > > This is not the case for python-ldap functions. Sometime when calling > python-ldap, we don't know well the origin ( a function is not suposed > to know its caller :-) of the arguments we are using : user input, > web interface, mysql database, ldap result, web form, > literal, text file, text parsing... some are unicode, other not. > I thing python-ldap function must accept unicode arguments. > > As we discussed at length previously, the decoding of the result is > less easy because, the library cannot guess alone the meaning of > these values. > > I'm not supporting the idea of downloading and use the ldap > schema. I cannot imaging a connection less application > like a web application doing that at any request! Or keeping a cache > for the schema ... > > Anyway I see 2 solutions > > 1. Let result() return non unicode strings. _HERE_ The user know all > returned > strings are normal strings utf-8 encoded and he can do the encoding > himself. A helper function doing the job for the result structure > should be welcome. > > 2. Do the conversion regarding the info provided in the query, as my > source sample does. > > I answer now some of your previous comment: > > > > In this case maybe is it possible to use [ '*', u'givenName', u'sn' ] > > > to convert only 'givenName' and 'sn' > > > But then you will not gain much! Still the application has to know which > > attributes have to be converted. => It's not worth hiding the conversion > > > within python-ldap. > > I don't really hide the conversion, because the user has to request it > using > unicode field name. And second, I do more work: I keep a link between > the msgid and the request to know with fields I have to convert and > also destroy the link when unneeded anymore. > > > The only clean solution would be something involving LDAP schema > processing! > > You know better than me how costly it is, in developing time, and its > overhead for CPU and network load. > Do you really consider to add the schema processing for unicode > integration in the future? Or are you > hoping that someone will send you a patch :-) ? > > > I know you were not very exited by my ideas, anyway the unicode support > for > argument encoding is important. (this is my opinion) > Feel free to suggest some cosmetic changes: function name, class name, the > > way I wrap your base class ..... > > Keep in mind, none of my code break compatibility with existing > application. > > Best regards. > > > > On 5/24/07, Alain Spineux wrote: > > > > > > > > On 5/24/07, Michael Str?der < michael at stroeder.com> wrote: > > > > > > Alain Spineux wrote: > > > > > > > > Yes but what about unknown field type ? > > > > > > If you really want to dive into this look in directory > > > pylib/w2lapp/schema/ of web2ldap's source. It works for me but I did > > > not > > > consider this whole framework mature enough to be incorporated into > > > python-ldap. > > > > > > I dont want to look at the schema: > > > > Here are the sources and the results. > > I use your more appropriate name for unicode testing :-) > > > > > > #!/usr/bin/env python2.4 > > > > import sys, os, time > > import ldap, ldapurl, ldap.modlist > > import types > > import datetime > > > > host='localhost' > > port=389 > > base_dn='dc=asxnet,dc=loc' > > > > if True: > > who='cn=manager,cn=internal,dc=asxnet,dc=loc' > > cred=''********' > > else: > > who='cn=nobody,cn=internal,dc=asxnet,dc=loc' > > cred='iMmTWz5pJ+lwY7i6M/BU61ngo1aBLyqQhRrrKbEc' > > > > > > def unicode2utf8(st): > > """Convert unicode (and only unicode) string into utf-8 raw string > > as expected by ldap""" > > > > if isinstance(st, types.UnicodeType ): > > return st.encode('utf-8') > > else: > > return st > > > > def utf82unicode(st): > > """encode st into utf-8""" > > return st.decode('utf-8') > > > > > > def encode_modlist(modlist, no_op): > > """encode ldap modlist structure > > set no_op=True for Tuple of kind (int,str,[str,...]) > > and False for (str, [str,...]) > > """ > > > > for i, mod in enumerate(modlist): > > if no_op: > > attr_name, attr_values=mod > > else: > > op, attr_name, attr_values=mod > > > > attr_name=unicode2utf8(attr_name) > > if isinstance(attr_values, ( types.ListType, types.TupleType)): > > attr_values=map(unicode2utf8, attr_values) > > else: > > attr_values=unicode2utf8(attr_values) > > if no_op: > > modlist[i]=(attr_name, attr_values) > > else: > > modlist[i]=(op, attr_name, attr_values) > > > > return modlist > > > > class UnicodeLDAPObject(ldap.ldapobject.LDAPObject): > > > > expiration_delay=300 > > > > def __init__(self, uri, **kwargs): > > ldap.ldapobject.LDAPObject.__init__(self, uri, **kwargs) > > self.unicode_decoder={} # (msgid, expiration, decoder_data) > > # I use an expiration time to avoid the list to become to big > > when the > > # server don't answere any request > > > > def search_ext(self,base,scope, filterstr, attrlist, *args, > > **kwargs): > > # base,scope, > > filterstr='(objectClass=*)',attrlist=None,attrsonly=0,serverctrls=None,clientctrls=None,timeout=-1,sizelimit=0 > > > > > > # convert filter > > filterstr=unicode2utf8(filterstr) > > > > # convert arglist and keep a copy of original values for later > > decoding > > > > u_attrlist=attrlist > > decoder={} > > if u_attrlist!=None: > > attrlist=[] > > for attr in u_attrlist: > > if isinstance(attr, types.UnicodeType): > > attr=attr.encode('utf-8') > > # print 'ATTR', attr > > decoder[attr]=True > > attrlist.append(attr) > > > > msgid=ldap.ldapobject.LDAPObject.search_ext(self,base,scope, > > filterstr, attrlist, *args, **kwargs) > > > > if decoder: > > timeout=kwargs.get('timeout', None) > > if timeout==None or timeout<=0: > > timeout=self.expiration_delay > > self.unicode_decoder[msgid]=(msgid, datetime.datetime.now()+datetime.timedelta(seconds=timeout), decoder) > > return msgid > > > > def result3(self, *args, **kwargs): > > # kwargs=(self, msgid=_ldap.RES_ANY,all=1,timeout=None): > > rtype, rdata, rmsgid, decoded_serverctrls= > > ldap.ldapobject.LDAPObject.result3(self, *args, **kwargs) > > > > if self.unicode_decoder.has_key(rmsgid): > > msgid, expire, decoder=self.unicode_decoder[rmsgid] > > if rtype not in [ ldap.RES_SEARCH_ENTRY, > > ldap.RES_SEARCH_REFERENCE ]: > > # this was the last result > > del self.unicode_decoder[rmsgid] > > else: > > # reset the timeout > > timeout= kwargs.get('timeout', None) > > if timeout==None or timeout<=0: > > timeout=self.expiration_delay > > self.unicode_decoder[msgid]=(msgid, > > datetime.datetime.now()+datetime.timedelta(seconds=timeout), decoder) > > > > # now decode the result > > if rdata: > > if rtype in [ldap.RES_SEARCH_ENTRY, > > ldap.RES_SEARCH_REFERENCE, ldap.RES_SEARCH_RESULT]: > > # FIXME: I dont know what is a RES_SEARCH_REFERENCE > > rdata_u=[] > > for i, (dn, attrs) in enumerate(rdata): > > # FIXME: should I handle the 'dn' the same way > > if decoder.has_key ('dn'): > > dn=utf82unicode(dn) > > for key in attrs.keys(): > > if decoder.has_key(key): > > attrs[key]=map(utf82unicode, attrs[key]) > > > > # print '\tITEM=', dn, attrs > > rdata[i]=(dn, attrs) > > > > else: > > # no decoder for this => nothing to decode > > pass > > > > # remove other expired decoder info > > now=datetime.datetime.now() > > for msgid in self.unicode_decoder.keys(): > > if self.unicode_decoder[rmsgid][1] > del self.unicode_decoder[rmsgid] > > > > return rtype, rdata, rmsgid, decoded_serverctrls > > > > def add_ext(self, dn, modlist, *args, **kwargs): > > # args=(self,dn,modlist,serverctrls=None,clientctrls=None) > > dn=unicode2utf8(dn) > > # print 'MODLIST', modlist > > modlist=encode_modlist(modlist, True) > > # print 'MODLIST unicode', modlist > > return ldap.ldapobject.LDAPObject.add_ext (self, dn, modlist, > > *args, **kwargs) > > > > def modify_ext(self, dn, modlist, *args, **kwargs): > > # args=(self,dn,modlist,serverctrls=None,clientctrls=None) > > dn=unicode2utf8(dn) > > # print 'MODLIST', modlist > > modlist=encode_modlist(modlist, False) > > # print 'MODLIST unicode', modlist > > return ldap.ldapobject.LDAPObject.modify_ext(self, dn, modlist, > > *args, **kwargs) > > > > def delete_ext(self, dn, *args, **kwargs): > > # args=(self,dn,serverctrls=None,clientctrls=None) > > dn=unicode2utf8(dn) > > return ldap.ldapobject.LDAPObject.delete_ext(self, dn, *args, > > **kwargs) > > > > > > > > def print_ldap_result(ldap_result): > > for dn, item in ldap_result: > > print 'DN=', repr(dn) > > for k, v in item.iteritems(): > > print '\t%s: %s' % (k, repr(v)) > > print > > > > ldap_url=ldapurl.LDAPUrl ('ldap://%s:%d/%s' % (host, port, base_dn)) > > ldap_url.applyDefaults({ > > 'who': who, > > 'cred' : cred, }) > > #l=ldap.ldapobject.LDAPObject(ldap_url.initializeUrl()) > > l=UnicodeLDAPObject(ldap_url.initializeUrl()) > > l.simple_bind_s(ldap_url.who, ldap_url.cred) > > print 'Connected as', l.whoami_s() > > > > > > first_name='Michael' > > first_name2=u'Micha\xebl' > > last_name=u'Str\xf6der' > > email=' michael at stroeder.com' > > street=u'Hauptstra\xe1e' > > country='Germany' > > > > cn='%s %s' %(first_name, last_name) > > dn='cn=%s,%s' %(cn, base_dn) > > info={ > > u'cn' : (cn, ), > > 'mail' : (email, ), > > 'objectClass' : ('top', 'inetOrgPerson', 'kolabInetOrgPerson',), > > u'sn' : (last_name, ), > > u'givenName' : (first_name, ), > > u'street': (street, ), > > 'c': (country, ), > > 'telephoneNumber': '+49 1111111111', > > } > > > > ldap_result=l.search_s(base_dn, ldap.SCOPE_ONELEVEL , '(cn=%s)' % (cn,) > > , info.keys()) > > if ldap_result: > > print '== Found' > > print_ldap_result(ldap_result) > > l.delete_s(dn) > > print '== Deleted' > > > > l.add_s(dn, ldap.modlist.addModlist (info)) > > print '== Created' > > ldap_result=l.search_s(base_dn, ldap.SCOPE_ONELEVEL, '(cn=%s)' % (cn,) , > > info.keys()) > > print_ldap_result(ldap_result) > > > > l.modify_s(dn, [(ldap.MOD_REPLACE, u'givenName', first_name2), > > (ldap.MOD_ADD, 'telephoneNumber', ( '+49 1234567890', > > )), > > ]) > > > > print '==Modified' > > ldap_result=l.search_s(base_dn, ldap.SCOPE_ONELEVEL, '(cn=%s)' % (cn,) , > > info.keys()) > > print_ldap_result(ldap_result) > > > > print '==Display once more' > > ldap_result=l.search_s(base_dn, ldap.SCOPE_ONELEVEL, '(cn=%s)' % (cn,) , > > ['*', '+', u'dn', u'givenName', u'creatorsName'] ) > > print_ldap_result(ldap_result) > > > > > > > > ============= > > > > > > Connected as dn:cn=manager,cn=internal,dc=asxnet,dc=loc > > == Found > > DN= 'cn=Michael Str\xc3\xb6der,dc=asxnet,dc=loc' > > telephoneNumber: ['+49 1111111111', '+49 1234567890'] > > c: ['Germany'] > > cn: [u'Michael Str\xf6der'] > > objectClass: ['top', 'inetOrgPerson', 'kolabInetOrgPerson'] > > street: [u'Hauptstra\xe1e'] > > sn: [u'Str\xf6der'] > > mail: ['michael at stroeder.com'] > > givenName: [u'Micha\xebl'] > > > > == Deleted > > == Created > > DN= 'cn=Michael Str\xc3\xb6der,dc=asxnet,dc=loc' > > telephoneNumber: ['+49 1111111111'] > > c: ['Germany'] > > cn: [u'Michael Str\xf6der'] > > objectClass: ['top', 'inetOrgPerson', 'kolabInetOrgPerson'] > > street: [u'Hauptstra\xe1e'] > > sn: [u'Str\xf6der'] > > mail: ['michael at stroeder.com '] > > givenName: [u'Michael'] > > > > ==Modified > > DN= 'cn=Michael Str\xc3\xb6der,dc=asxnet,dc=loc' > > telephoneNumber: ['+49 1111111111', '+49 1234567890'] > > c: ['Germany'] > > cn: [u'Michael Str\xf6der'] > > objectClass: ['top', 'inetOrgPerson', 'kolabInetOrgPerson'] > > street: [u'Hauptstra\xe1e'] > > sn: [u'Str\xf6der'] > > mail: [' michael at stroeder.com'] > > givenName: [u'Micha\xebl'] > > > > ==Display more > > DN= 'cn=Michael Str\xc3\xb6der,dc=asxnet,dc=loc' > > telephoneNumber: ['+49 1111111111', '+49 1234567890'] > > c: ['Germany'] > > cn: [u'Michael Str\xf6der'] > > objectClass: ['top', 'inetOrgPerson', 'kolabInetOrgPerson'] > > street: [u'Hauptstra\xe1e'] > > sn: [u'Str\xf6der'] > > mail: ['michael at stroeder.com'] > > givenName: [u'Micha\xebl'] > > > > ==Display once more > > DN= u'cn=Michael Str\xf6der,dc=asxnet,dc=loc' > > telephoneNumber: ['+49 1111111111', '+49 1234567890'] > > c: ['Germany'] > > entryCSN: ['20070524191126Z#000002#00#000000'] > > cn: ['Michael Str\xc3\xb6der'] > > entryDN: ['cn=Michael Str\xc3\xb6der,dc=asxnet,dc=loc'] > > createTimestamp: ['20070524191126Z'] > > objectClass: ['top', 'inetOrgPerson', 'kolabInetOrgPerson'] > > creatorsName: [u'cn=manager,cn=internal,dc=asxnet,dc=loc'] > > entryUUID: ['5099e82e-9e76-102b-830b-0da78c7bd35e'] > > hasSubordinates: ['FALSE'] > > modifiersName: ['cn=manager,cn=internal,dc=asxnet,dc=loc'] > > street: ['Hauptstra\xc3\xa1e'] > > sn: ['Str\xc3\xb6der'] > > structuralObjectClass: ['inetOrgPerson'] > > subschemaSubentry: ['cn=Subschema'] > > mail: [' michael at stroeder.com'] > > givenName: [u'Micha\xebl'] > > modifyTimestamp: ['20070524191126Z'] > > > > > > > > > > > > -- > > -- > > Alain Spineux > > aspineux gmail com > > May the sources be with you > > > > > > -- > -- > Alain Spineux > aspineux gmail com > May the sources be with you > -- -- Alain Spineux aspineux gmail com May the sources be with you -------------- next part -------------- An HTML attachment was scrubbed... URL: From ahasenack at terra.com.br Fri Jun 1 00:23:36 2007 From: ahasenack at terra.com.br (Andreas Hasenack) Date: Thu, 31 May 2007 19:23:36 -0300 Subject: controls and BER encoding of its values In-Reply-To: <465B1A4D.60409@stroeder.com> References: <20070528130819.GC3622@mandriva.com.br> <465B1A4D.60409@stroeder.com> Message-ID: <20070531222336.GB23226@mandriva.com.br> On Mon, May 28, 2007 at 08:07:09PM +0200, Michael Str?der wrote: > Andreas Hasenack wrote: > > > > last Friday I played a bit with controls in python-ldap. I was trying to > > get the matched-values control (LDAP_CONTROL_VALUESRETURNFILTER) to > > work. > > Feel free to contribute your results. > > > It seems I have to manually do the BER encoding of the values. I googled > > for some modules and pyasn1 seems to be the most complete one, but I > > would have to basically write classes for the whole LDAP spec :( > > You can use pyasn1 for just creating the BER en-/decoding the control > values. Please look into Lib/ldap/controls.py to get the idea how you > can implement the methods for encoding and decoding in sub-classes of > ldap.controls.LDAPControl. I think it worked. Luckily in my case the OpenLDAP library already has a function called ldap_put_vrFilter() which I could use to do all the encoding of a ValuesReturn filter. Using a bit of monkey see, monkey do, I have such a filter working now: mv = MatchedValuesControl(criticality=True,"(mail=*@example.com)") res = ld.search_ext_s(base, scope, filter, attrlist = ['mail'], serverctrls = [mv]) In this example, if the entry matching the filter has: mail: foo at example.com mail: foo at example.org The result will only have "mail: foo at example.com". Without the control, the result would have both mail attributes. I will still see about the decode part and then post what I have. From michael at stroeder.com Fri Jun 1 00:51:08 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 01 Jun 2007 00:51:08 +0200 Subject: controls and BER encoding of its values In-Reply-To: <20070531222336.GB23226@mandriva.com.br> References: <20070528130819.GC3622@mandriva.com.br> <465B1A4D.60409@stroeder.com> <20070531222336.GB23226@mandriva.com.br> Message-ID: <465F515C.5060501@stroeder.com> Andreas Hasenack wrote: > > Luckily in my case the OpenLDAP library already has a > function called ldap_put_vrFilter() which I could use to do all the > encoding of a ValuesReturn filter. > [..] > I will still see about the decode part and then post what I have. Since which version of OpenLDAP is ldap_put_vrFilter() present? Ciao, Michael. From aspineux at gmail.com Fri Jun 1 01:26:59 2007 From: aspineux at gmail.com (Alain Spineux) Date: Fri, 1 Jun 2007 01:26:59 +0200 Subject: patch: change sasl.h into sasl/sasl.h Message-ID: <71fe4e760705311626r4299785ej237299c0cc2399fe@mail.gmail.com> Hello May I suggest to change (in file LDAPObject.c ) > #include into > #include That way you can change (in file setup.cfg) > library_dirs = /usr/local/openldap-2.3/lib > include_dirs = /usr/local/openldap-2.3/include /usr/include/sasl into > library_dirs = /usr/local/openldap-2.3/lib > include_dirs = /usr/local/openldap-2.3/include That way gcc will use its own header location and not use the one installed in /usr/include/sasl by any linux distribution This is useful when having multiple version of gcc ... That way on my own system I don't need tu update setup.cfg. I hope this will do the same for lot of other user. I looked in cyrus-imapd source, all files use ! Here is the patch Best regards. Alain diff -r -c python-ldap-2.3.orig/Modules/LDAPObject.c python-ldap-2.3 /Modules/LDAPObject.c *** python-ldap-2.3.orig/Modules/LDAPObject.c Tue Mar 27 22:34:31 2007 --- python-ldap-2.3/Modules/LDAPObject.c Fri Jun 1 01:01:50 2007 *************** *** 18,24 **** #include "options.h" #ifdef HAVE_SASL ! #include #endif static void free_attrs(char***); --- 18,24 ---- #include "options.h" #ifdef HAVE_SASL ! #include #endif static void free_attrs(char***); diff -r -c python-ldap-2.3.orig/setup.cfg python-ldap-2.3/setup.cfg *** python-ldap-2.3.orig/setup.cfg Wed Nov 15 18:26:26 2006 --- python-ldap-2.3/setup.cfg Fri Jun 1 01:02:04 2007 *************** *** 8,14 **** [_ldap] library_dirs = /usr/local/openldap-2.3/lib ! include_dirs = /usr/local/openldap-2.3/include /usr/include/sasl extra_compile_args = extra_objects = --- 8,14 ---- [_ldap] library_dirs = /usr/local/openldap-2.3/lib ! include_dirs = /usr/local/openldap-2.3/include extra_compile_args = extra_objects = -- -- Alain Spineux aspineux gmail com May the sources be with you -------------- next part -------------- An HTML attachment was scrubbed... URL: From ahasenack at terra.com.br Fri Jun 1 02:04:19 2007 From: ahasenack at terra.com.br (Andreas Hasenack) Date: Thu, 31 May 2007 21:04:19 -0300 Subject: controls and BER encoding of its values In-Reply-To: <465F515C.5060501@stroeder.com> References: <20070528130819.GC3622@mandriva.com.br> <20070531222336.GB23226@mandriva.com.br> <465F515C.5060501@stroeder.com> Message-ID: <200705312104.19868.ahasenack@terra.com.br> On Thursday 31 May 2007 19:51:08 Michael Str?der wrote: > Andreas Hasenack wrote: > > Luckily in my case the OpenLDAP library already has a > > function called ldap_put_vrFilter() which I could use to do all the > > encoding of a ValuesReturn filter. > > [..] > > I will still see about the decode part and then post what I have. > > Since which version of OpenLDAP is ldap_put_vrFilter() present? I don't know. I only checked /usr/include/ldap.h to make sure it's a public function and not an internal one. From chaoseternal at gmail.com Fri Jun 1 10:44:32 2007 From: chaoseternal at gmail.com (Chaos Eternal) Date: Fri, 1 Jun 2007 16:44:32 +0800 Subject: controls and BER encoding of its values In-Reply-To: <200705312104.19868.ahasenack@terra.com.br> References: <20070528130819.GC3622@mandriva.com.br> <20070531222336.GB23226@mandriva.com.br> <465F515C.5060501@stroeder.com> <200705312104.19868.ahasenack@terra.com.br> Message-ID: <6456782e0706010144h4eb0365ds7f723165e4dfad3a@mail.gmail.com> I have tested LDAP Server Side Sort with Novell's eDirectory 8.8.1 using BER constructor form LDAPTOR project and python-ldap's ldap interface. from my side, it works. so why not try LDAPTOR's BER constructor for your purpose? On 6/1/07, Andreas Hasenack wrote: > > On Thursday 31 May 2007 19:51:08 Michael Str?der wrote: > > Andreas Hasenack wrote: > > > Luckily in my case the OpenLDAP library already has a > > > function called ldap_put_vrFilter() which I could use to do all the > > > encoding of a ValuesReturn filter. > > > [..] > > > I will still see about the decode part and then post what I have. > > > > Since which version of OpenLDAP is ldap_put_vrFilter() present? > > I don't know. I only checked /usr/include/ldap.h to make sure it's a > public > function and not an internal one. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Python-LDAP-dev mailing list > Python-LDAP-dev at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/python-ldap-dev > -- Best Regards Chaos Eternal -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Fri Jun 1 12:00:11 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 01 Jun 2007 12:00:11 +0200 Subject: patch: change sasl.h into sasl/sasl.h In-Reply-To: <71fe4e760705311626r4299785ej237299c0cc2399fe@mail.gmail.com> References: <71fe4e760705311626r4299785ej237299c0cc2399fe@mail.gmail.com> Message-ID: <465FEE2B.4020302@stroeder.com> Alain Spineux wrote: > > May I suggest to change (in file LDAPObject.c ) > >> #include > > into > >> #include > > That way you can change (in file setup.cfg) > >> library_dirs = /usr/local/openldap- 2.3/lib >> include_dirs = /usr/local/openldap-2.3/include /usr/include/sasl > > into > >> library_dirs = /usr/local/openldap-2.3/lib >> include_dirs = /usr/local/openldap-2.3/include > > That way gcc will use its own header location and not use the > one installed in /usr/include/sasl by any linux distribution > This is useful when having multiple version of gcc ... > > That way on my own system I don't need tu update setup.cfg. Alain, this seems to make sense. But are you sure that it's valid for all versions of Cyrus-SASL? I'd love to accept this change but I wonder whether it will break older installations. Note that you can correct the current include-statement by tweaking setup.cfg. But not the other way. In OpenLDAP sources the following construct is used: #ifdef HAVE_SASL_SASL_H #include #else #include #endif I guess HAVE_SASL_SASL_H is set by autoconf though. Ciao, Michael. From aspineux at gmail.com Fri Jun 1 13:19:35 2007 From: aspineux at gmail.com (Alain Spineux) Date: Fri, 1 Jun 2007 13:19:35 +0200 Subject: patch: change sasl.h into sasl/sasl.h In-Reply-To: <465FEE2B.4020302@stroeder.com> References: <71fe4e760705311626r4299785ej237299c0cc2399fe@mail.gmail.com> <465FEE2B.4020302@stroeder.com> Message-ID: <71fe4e760706010419g209d49b3v8b8991c45565c29d@mail.gmail.com> On 6/1/07, Michael Str?der wrote: > > Alain Spineux wrote: > > > > May I suggest to change (in file LDAPObject.c ) > > > >> #include > > > > into > > > >> #include > > > > That way you can change (in file setup.cfg) > > > >> library_dirs = /usr/local/openldap- 2.3/lib > >> include_dirs = /usr/local/openldap-2.3/include /usr/include/sasl > > > > into > > > >> library_dirs = /usr/local/openldap-2.3/lib > >> include_dirs = /usr/local/openldap-2.3/include > > > > That way gcc will use its own header location and not use the > > one installed in /usr/include/sasl by any linux distribution > > This is useful when having multiple version of gcc ... > > > > That way on my own system I don't need tu update setup.cfg. > > Alain, this seems to make sense. But are you sure that it's valid for > all versions of Cyrus-SASL? I No :-( I looked postfix sources and found about SASL 1.5.5 On some systems this generates the necessary Makefile definitions: (for SASL version 1.5.5): % make tidy # if you have left-over files from a previous build % make makefiles CCARGS="-DUSE_SASL_AUTH -I/usr/local/include" \ AUXLIBS="-L/usr/local/lib -lsasl" (for SASL version 2.1.1): % make tidy # if you have left-over files from a previous build % make makefiles CCARGS="-DUSE_SASL_AUTH -I/usr/local/include/sasl" \ AUXLIBS="-L/usr/local/lib -lsasl2" 'd love to accept this change but I wonder > whether it will break older installations. This is what I worry about. Note that you can correct the > current include-statement by tweaking setup.cfg. But not the other way. > > In OpenLDAP sources the following construct is used: > > #ifdef HAVE_SASL_SASL_H > #include > #else > #include > #endif > > I guess HAVE_SASL_SASL_H is set by autoconf though. Yes I saw that. Keep the idea in your mind, and a day, if you use like me a "tree rooted" system like openpkg, don't replace the current /usr/include/sasl with /openpkg/include/sasl/sasl.h, just apply my patch :-) Ciao, Michael. > Regards. Alain -- Alain Spineux aspineux gmail com May the sources be with you -------------- next part -------------- An HTML attachment was scrubbed... URL: From ahasenack at terra.com.br Fri Jun 1 14:07:41 2007 From: ahasenack at terra.com.br (Andreas Hasenack) Date: Fri, 1 Jun 2007 09:07:41 -0300 Subject: controls and BER encoding of its values In-Reply-To: <6456782e0706010144h4eb0365ds7f723165e4dfad3a@mail.gmail.com> References: <20070528130819.GC3622@mandriva.com.br> <20070531222336.GB23226@mandriva.com.br> <465F515C.5060501@stroeder.com> <200705312104.19868.ahasenack@terra.com.br> <6456782e0706010144h4eb0365ds7f723165e4dfad3a@mail.gmail.com> Message-ID: <20070601120740.GA3204@mandriva.com.br> On Fri, Jun 01, 2007 at 04:44:32PM +0800, Chaos Eternal wrote: > I have tested LDAP Server Side Sort with Novell's eDirectory 8.8.1 using > BER constructor form LDAPTOR project and python-ldap's ldap interface. > from my side, it works. > so why not try LDAPTOR's BER constructor for your purpose? I think I would really like something like openldap's ber_printf routines. Seems fairly easy to construct these sequences with it. I don't know about LAPTOR, never heard of it before. Is it some sort of python interface to liblber? (Yes, I know, I can google it :P) From ahasenack at terra.com.br Fri Jun 1 14:16:11 2007 From: ahasenack at terra.com.br (Andreas Hasenack) Date: Fri, 1 Jun 2007 09:16:11 -0300 Subject: controls and BER encoding of its values In-Reply-To: <465F515C.5060501@stroeder.com> References: <20070528130819.GC3622@mandriva.com.br> <465B1A4D.60409@stroeder.com> <20070531222336.GB23226@mandriva.com.br> <465F515C.5060501@stroeder.com> Message-ID: <20070601121611.GC3204@mandriva.com.br> On Fri, Jun 01, 2007 at 12:51:08AM +0200, Michael Str?der wrote: > Andreas Hasenack wrote: > > > > Luckily in my case the OpenLDAP library already has a > > function called ldap_put_vrFilter() which I could use to do all the > > encoding of a ValuesReturn filter. > > [..] > > I will still see about the decode part and then post what I have. > > Since which version of OpenLDAP is ldap_put_vrFilter() present? Found it in the first public 2.3.x version (2.3.4) and also in late 2.2.x versions. I didn't check further back. So I guess it would be OK to use it, given that python-ldap currently requires openldap 2.3.x. From ahasenack at terra.com.br Fri Jun 1 16:27:45 2007 From: ahasenack at terra.com.br (Andreas Hasenack) Date: Fri, 1 Jun 2007 11:27:45 -0300 Subject: [PATCH] RFC 3876 control (return values filter) Message-ID: <20070601142745.GA4388@mandriva.com.br> On Thu, May 31, 2007 at 07:23:36PM -0300, Andreas Hasenack wrote: > I will still see about the decode part and then post what I have. Attached is my current patch. Keep in mind I did this basically using the current code as a template. I ended up not implementing the decode part, I'm not sure for what it would be needed. Just for completeness? -------------- next part -------------- Index: Modules/constants.c =================================================================== --- Modules/constants.c +++ Modules/constants.c 2007-06-01 11:12:12.000000000 -0300 @@ -262,4 +262,8 @@ PyDict_SetItemString( d, "LDAP_CONTROL_PAGE_OID", obj ); Py_DECREF(obj); + obj = PyString_FromString(LDAP_CONTROL_VALUESRETURNFILTER); + PyDict_SetItemString( d, "LDAP_CONTROL_VALUESRETURNFILTER", obj ); + Py_DECREF(obj); + } Index: Modules/constants.h =================================================================== --- Modules/constants.h +++ Modules/constants.h 2007-06-01 11:12:12.000000000 -0300 @@ -12,4 +12,8 @@ #define LDAP_CONTROL_PAGE_OID "1.2.840.113556.1.4.319" #endif /* !LDAP_CONTROL_PAGE_OID */ +#ifndef LDAP_CONTROL_VALUESRETURNFILTER +#define LDAP_CONTROL_VALUESRETURNFILTER "1.2.826.0.1.3344810.2.3" /* RFC 3876 */ +#endif /* !LDAP_CONTROL_VALUESRETURNFILTER */ + #endif /* __h_constants_ */ Index: Modules/ldapcontrol.c =================================================================== --- Modules/ldapcontrol.c +++ Modules/ldapcontrol.c 2007-06-01 11:12:12.000000000 -0300 @@ -201,6 +201,46 @@ /* --------------- en-/decoders ------------- */ +/* Matched Values, aka, Values Return Filter */ +static PyObject* +encode_rfc3876(PyObject *self, PyObject *args) +{ + PyObject *res = 0; + int err; + BerElement *vrber = 0; + char *vrFilter; + struct berval *ctrl_val; + + if (!PyArg_ParseTuple(args, "s:encode_valuesreturnfilter_control", &vrFilter)) { + goto endlbl; + } + + if (!(vrber = ber_alloc_t(LBER_USE_DER))) { + LDAPerr(LDAP_NO_MEMORY); + goto endlbl; + } + + err = ldap_put_vrFilter(vrber, vrFilter); + if (err == -1) { + LDAPerr(LDAP_FILTER_ERROR); + goto endlbl; + } + + err = ber_flatten(vrber, &ctrl_val); + if (err == -1) { + LDAPerr(LDAP_NO_MEMORY); + goto endlbl; + } + + res = Py_BuildValue("s#", ctrl_val->bv_val, ctrl_val->bv_len); + +endlbl: + if (vrber) + ber_free(vrber, 1); + + return res; +} + static PyObject* encode_rfc2696(PyObject *self, PyObject *args) { @@ -293,6 +333,7 @@ static PyMethodDef methods[] = { {"encode_page_control", encode_rfc2696, METH_VARARGS }, {"decode_page_control", decode_rfc2696, METH_VARARGS }, + {"encode_valuesreturnfilter_control", encode_rfc3876, METH_VARARGS }, { NULL, NULL } }; Index: Lib/ldap/controls.py =================================================================== --- Lib/ldap/controls.py +++ Lib/ldap/controls.py 2007-06-01 11:18:51.000000000 -0300 @@ -82,6 +82,23 @@ return size,cookie +class MatchedValuesControl(LDAPControl): + """ + LDAP Matched Values control, as defined in RFC 3876 + + from ldap.controls import MatchedValuesControl + control = MatchedValuesControl(criticality, filter) + """ + + controlType = ldap.LDAP_CONTROL_VALUESRETURNFILTER + + def __init__(self, criticality, controlValue=None): + LDAPControl.__init__(self, self.controlType, criticality, controlValue, None) + + def encodeControlValue(self, value): + return _ldap.encode_valuesreturnfilter_control(value) + + def EncodeControlTuples(ldapControls): """ Return list of readily encoded 3-tuples which can be directly From chaoseternal at gmail.com Sun Jun 3 13:39:52 2007 From: chaoseternal at gmail.com (Chaos Eternal) Date: Sun, 3 Jun 2007 19:39:52 +0800 Subject: controls and BER encoding of its values In-Reply-To: <20070601120740.GA3204@mandriva.com.br> References: <20070528130819.GC3622@mandriva.com.br> <20070531222336.GB23226@mandriva.com.br> <465F515C.5060501@stroeder.com> <200705312104.19868.ahasenack@terra.com.br> <6456782e0706010144h4eb0365ds7f723165e4dfad3a@mail.gmail.com> <20070601120740.GA3204@mandriva.com.br> Message-ID: <6456782e0706030439g1b6f1a5dyac0e77ba0f7770ec@mail.gmail.com> Ldaptor is a pure-Python library that implements . - LDAP client logic. . - separately-accessible LDAP and BER protocol message generation/parsing. . - ASCII-format LDAP filter generation and parsing. . - LDIF format data generation. . - Samba password changing logic. . On 6/1/07, Andreas Hasenack wrote: > > On Fri, Jun 01, 2007 at 04:44:32PM +0800, Chaos Eternal wrote: > > I have tested LDAP Server Side Sort with Novell's eDirectory 8.8.1using > > BER constructor form LDAPTOR project and python-ldap's ldap interface. > > from my side, it works. > > so why not try LDAPTOR's BER constructor for your purpose? > > I think I would really like something like openldap's ber_printf > routines. Seems fairly easy to construct these sequences with it. I > don't know about LAPTOR, never heard of it before. Is it some sort of > python interface to liblber? (Yes, I know, I can google it :P) > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Python-LDAP-dev mailing list > Python-LDAP-dev at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/python-ldap-dev > -- Best Regards Chaos Eternal -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Sun Jun 3 14:45:09 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Sun, 03 Jun 2007 14:45:09 +0200 Subject: patch: change sasl.h into sasl/sasl.h In-Reply-To: <71fe4e760706010419g209d49b3v8b8991c45565c29d@mail.gmail.com> References: <71fe4e760705311626r4299785ej237299c0cc2399fe@mail.gmail.com> <465FEE2B.4020302@stroeder.com> <71fe4e760706010419g209d49b3v8b8991c45565c29d@mail.gmail.com> Message-ID: <4662B7D5.8090106@stroeder.com> Alain Spineux wrote: > > On 6/1/07, *Michael Str?der* > wrote: > > Alain Spineux wrote: > > > > May I suggest to change (in file LDAPObject.c ) > >> #include > > into > >> #include > > Alain, this seems to make sense. But are you sure that it's valid for > all versions of Cyrus-SASL? I > > No :-( So let's keep it as it is. Ciao, Michael. From aspineux at gmail.com Mon Jun 4 13:30:52 2007 From: aspineux at gmail.com (Alain Spineux) Date: Mon, 4 Jun 2007 13:30:52 +0200 Subject: patch: change sasl.h into sasl/sasl.h In-Reply-To: <4662B7D5.8090106@stroeder.com> References: <71fe4e760705311626r4299785ej237299c0cc2399fe@mail.gmail.com> <465FEE2B.4020302@stroeder.com> <71fe4e760706010419g209d49b3v8b8991c45565c29d@mail.gmail.com> <4662B7D5.8090106@stroeder.com> Message-ID: <71fe4e760706040430scd57ab4kd0e94245f8961c3b@mail.gmail.com> On 6/3/07, Michael Str?der wrote: > > Alain Spineux wrote: > > > > Alain, this seems to make sense. But are you sure that it's valid > for > > all versions of Cyrus-SASL? I > > > > No :-( > > So let's keep it as it is. Right. Ciao, Michael. > > Regards -- -- Alain Spineux aspineux gmail com May the sources be with you -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Mon Jun 4 13:30:47 2007 From: michael at stroeder.com (=?UTF-8?B?Ik1pY2hhZWwgU3Ryw7ZkZXIi?=) Date: Mon, 4 Jun 2007 13:30:47 +0200 Subject: controls and BER encoding of its values In-Reply-To: <4663AA90.5060002@adm.umu.se> References: <20070528130819.GC3622@mandriva.com.br> <20070531222336.GB23226@mandriva.com.br> <465F515C.5060501@stroeder.com> <200705312104.19868.ahasenack@terra.com.br> <6456782e0706010144h4eb0365ds7f723165e4dfad3a@mail.gmail.com> <20070601120740.GA3204@mandriva.com.br> <6456782e0706030439g1b6f1a5dyac0e77ba0f7770ec@mail.gmail.com> <4663AA90.5060002@adm.umu.se> Message-ID: On 8:00:48 am 2007-06-04 Roland Hedberg wrote: > Chaos Eternal wrote: > > Ldaptor is a pure-Python library that implements > > That it is, but do anyone know if it is actively maintained ? > > Looking at the Trac-page for the project > (http://www.inoi.fi/open/trac/ldaptor) , it seems that nothing has > happend with ldaptor since 2005. IIRC I've contacted the author to join forces several years ago. No response. Ciao, Michael. From michael at stroeder.com Mon Jun 4 16:06:29 2007 From: michael at stroeder.com (=?UTF-8?B?Ik1pY2hhZWwgU3Ryw7ZkZXIi?=) Date: Mon, 4 Jun 2007 16:06:29 +0200 Subject: controls and BER encoding of its values In-Reply-To: <6456782e0706040519m1487babbs4488e0382a052286@mail.gmail.com> References: <20070528130819.GC3622@mandriva.com.br> <20070531222336.GB23226@mandriva.com.br> <465F515C.5060501@stroeder.com> <200705312104.19868.ahasenack@terra.com.br> <6456782e0706010144h4eb0365ds7f723165e4dfad3a@mail.gmail.com> <20070601120740.GA3204@mandriva.com.br> <6456782e0706030439g1b6f1a5dyac0e77ba0f7770ec@mail.gmail.com> <4663AA90.5060002@adm.umu.se> <6456782e0706040519m1487babbs4488e0382a052286@mail.gmail.com> Message-ID: HI! Don't want to blame anybody but it seems unfeasible to determine the status of the ldaptor project. Therefore I prefer not to rely on it at all. And IIRC it's strictly GPL. python-ldap has a more liberal license. Therefore we cannot copy code from it. Ciao, Michael. On 2:19:03 pm 2007-06-04 "Chaos Eternal" wrote: > oops, I forget to check the activity. > but from Debian's view: http://packages.qa.debian.org/l/ldaptor.html > , the project's activity lasts until Oct, 2006. > > On 6/4/07, Roland Hedberg wrote: > > > > Chaos Eternal wrote: > > > Ldaptor is a pure-Python library that implements > > > > That it is, but do anyone know if it is actively maintained ? > > > > Looking at the Trac-page for the project > > (http://www.inoi.fi/open/trac/ldaptor) , it seems that nothing has > > happend with ldaptor since 2005. > > > > -- Roland From ahasenack at terra.com.br Mon Jun 4 23:49:49 2007 From: ahasenack at terra.com.br (Andreas Hasenack) Date: Mon, 4 Jun 2007 18:49:49 -0300 Subject: [PATCH] support RFC4525 modify+increment extension Message-ID: <20070604214949.GJ3108@mandriva.com.br> Attached. Simple example: print "Before:" print ld.search_s(BASE, ldap.SCOPE_SUBTREE, "(objectClass=sambaUnixIdPool)", ['uidNumber']) modlist = [(ldap.MOD_INCREMENT, "uidNumber", "1")] res = ld.modify_s("cn=unixIdPool,dc=example,dc=com", modlist) print "After:" print ld.search_s(BASE, ldap.SCOPE_SUBTREE, "(objectClass=sambaUnixIdPool)", ['uidNumber']) Output: $ ./modify+increment.py Before: [('cn=unixIdPool,dc=example,dc=com', {'uidNumber': ['1042']})] After: [('cn=unixIdPool,dc=example,dc=com', {'uidNumber': ['1043']})] -------------- next part -------------- Index: Modules/constants.c =================================================================== --- Modules/constants.c +++ Modules/constants.c 2007-06-04 18:32:18.000000000 -0300 @@ -123,6 +123,7 @@ add_int(d,MOD_ADD); add_int(d,MOD_DELETE); add_int(d,MOD_REPLACE); + add_int(d,MOD_INCREMENT); add_int(d,MOD_BVALUES); add_int(d,MSG_ONE); Index: Lib/ldap/ldapobject.py =================================================================== --- Lib/ldap/ldapobject.py +++ Lib/ldap/ldapobject.py 2007-06-04 18:48:42.000000000 -0300 @@ -310,13 +310,13 @@ dn is the DN of the entry to modify, and modlist is the list of modifications to make to the entry. - Each element of the list modlist should be a tuple of the form - (mod_op,mod_type,mod_vals), where mod_op is the operation (one - of MOD_ADD, MOD_DELETE, or MOD_REPLACE), mod_type is a string - indicating the attribute type name, and mod_vals is either - a string value or a list of string values to add, delete or - replace respectively. For the delete operation, mod_vals may - be None indicating that all attributes are to be deleted. + Each element of the list modlist should be a tuple of the form + (mod_op,mod_type,mod_vals), where mod_op is the operation (one of + MOD_ADD, MOD_DELETE, MOD_INCREMENT or MOD_REPLACE), mod_type is a + string indicating the attribute type name, and mod_vals is either a + string value or a list of string values to add, delete, increment by or + replace respectively. For the delete operation, mod_vals may be None + indicating that all attributes are to be deleted. The asynchronous modify() returns the message id of the initiated request. From roland.hedberg at adm.umu.se Mon Jun 4 08:00:48 2007 From: roland.hedberg at adm.umu.se (Roland Hedberg) Date: Mon, 04 Jun 2007 08:00:48 +0200 Subject: controls and BER encoding of its values In-Reply-To: <6456782e0706030439g1b6f1a5dyac0e77ba0f7770ec@mail.gmail.com> References: <20070528130819.GC3622@mandriva.com.br> <20070531222336.GB23226@mandriva.com.br> <465F515C.5060501@stroeder.com> <200705312104.19868.ahasenack@terra.com.br> <6456782e0706010144h4eb0365ds7f723165e4dfad3a@mail.gmail.com> <20070601120740.GA3204@mandriva.com.br> <6456782e0706030439g1b6f1a5dyac0e77ba0f7770ec@mail.gmail.com> Message-ID: <4663AA90.5060002@adm.umu.se> Chaos Eternal wrote: > Ldaptor is a pure-Python library that implements That it is, but do anyone know if it is actively maintained ? Looking at the Trac-page for the project (http://www.inoi.fi/open/trac/ldaptor) , it seems that nothing has happend with ldaptor since 2005. -- Roland From chaoseternal at gmail.com Mon Jun 4 14:19:03 2007 From: chaoseternal at gmail.com (Chaos Eternal) Date: Mon, 4 Jun 2007 20:19:03 +0800 Subject: controls and BER encoding of its values In-Reply-To: <4663AA90.5060002@adm.umu.se> References: <20070528130819.GC3622@mandriva.com.br> <20070531222336.GB23226@mandriva.com.br> <465F515C.5060501@stroeder.com> <200705312104.19868.ahasenack@terra.com.br> <6456782e0706010144h4eb0365ds7f723165e4dfad3a@mail.gmail.com> <20070601120740.GA3204@mandriva.com.br> <6456782e0706030439g1b6f1a5dyac0e77ba0f7770ec@mail.gmail.com> <4663AA90.5060002@adm.umu.se> Message-ID: <6456782e0706040519m1487babbs4488e0382a052286@mail.gmail.com> oops, I forget to check the activity. but from Debian's view: http://packages.qa.debian.org/l/ldaptor.html , the project's activity lasts until Oct, 2006. On 6/4/07, Roland Hedberg wrote: > > Chaos Eternal wrote: > > Ldaptor is a pure-Python library that implements > > That it is, but do anyone know if it is actively maintained ? > > Looking at the Trac-page for the project > (http://www.inoi.fi/open/trac/ldaptor) , it seems that nothing has > happend with ldaptor since 2005. > > -- Roland > -- Best Regards Chaos Eternal -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Mon Jun 4 13:30:47 2007 From: michael at stroeder.com (=?UTF-8?B?Ik1pY2hhZWwgU3Ryw7ZkZXIi?=) Date: Mon, 4 Jun 2007 13:30:47 +0200 Subject: controls and BER encoding of its values In-Reply-To: <4663AA90.5060002@adm.umu.se> References: <20070528130819.GC3622@mandriva.com.br> <20070531222336.GB23226@mandriva.com.br> <465F515C.5060501@stroeder.com> <200705312104.19868.ahasenack@terra.com.br> <6456782e0706010144h4eb0365ds7f723165e4dfad3a@mail.gmail.com> <20070601120740.GA3204@mandriva.com.br> <6456782e0706030439g1b6f1a5dyac0e77ba0f7770ec@mail.gmail.com> <4663AA90.5060002@adm.umu.se> Message-ID: On 8:00:48 am 2007-06-04 Roland Hedberg wrote: > Chaos Eternal wrote: > > Ldaptor is a pure-Python library that implements > > That it is, but do anyone know if it is actively maintained ? > > Looking at the Trac-page for the project > (http://www.inoi.fi/open/trac/ldaptor) , it seems that nothing has > happend with ldaptor since 2005. IIRC I've contacted the author to join forces several years ago. No response. Ciao, Michael. From michael at stroeder.com Mon Jun 4 16:06:29 2007 From: michael at stroeder.com (=?UTF-8?B?Ik1pY2hhZWwgU3Ryw7ZkZXIi?=) Date: Mon, 4 Jun 2007 16:06:29 +0200 Subject: controls and BER encoding of its values In-Reply-To: <6456782e0706040519m1487babbs4488e0382a052286@mail.gmail.com> References: <20070528130819.GC3622@mandriva.com.br> <20070531222336.GB23226@mandriva.com.br> <465F515C.5060501@stroeder.com> <200705312104.19868.ahasenack@terra.com.br> <6456782e0706010144h4eb0365ds7f723165e4dfad3a@mail.gmail.com> <20070601120740.GA3204@mandriva.com.br> <6456782e0706030439g1b6f1a5dyac0e77ba0f7770ec@mail.gmail.com> <4663AA90.5060002@adm.umu.se> <6456782e0706040519m1487babbs4488e0382a052286@mail.gmail.com> Message-ID: HI! Don't want to blame anybody but it seems unfeasible to determine the status of the ldaptor project. Therefore I prefer not to rely on it at all. And IIRC it's strictly GPL. python-ldap has a more liberal license. Therefore we cannot copy code from it. Ciao, Michael. On 2:19:03 pm 2007-06-04 "Chaos Eternal" wrote: > oops, I forget to check the activity. > but from Debian's view: http://packages.qa.debian.org/l/ldaptor.html > , the project's activity lasts until Oct, 2006. > > On 6/4/07, Roland Hedberg wrote: > > > > Chaos Eternal wrote: > > > Ldaptor is a pure-Python library that implements > > > > That it is, but do anyone know if it is actively maintained ? > > > > Looking at the Trac-page for the project > > (http://www.inoi.fi/open/trac/ldaptor) , it seems that nothing has > > happend with ldaptor since 2005. > > > > -- Roland From michael at stroeder.com Tue Jun 5 11:56:48 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 05 Jun 2007 11:56:48 +0200 Subject: [PATCH] support RFC4525 modify+increment extension In-Reply-To: <20070604214949.GJ3108@mandriva.com.br> References: <20070604214949.GJ3108@mandriva.com.br> Message-ID: <46653360.3020702@stroeder.com> Andreas Hasenack wrote: > Attached. Ok. Committed it. Thanks. Ciao, Michael. From ahasenack at terra.com.br Tue Jun 5 23:12:41 2007 From: ahasenack at terra.com.br (Andreas Hasenack) Date: Tue, 5 Jun 2007 18:12:41 -0300 Subject: Experiments with pyasn1 and preread control Message-ID: <20070605211241.GF25341@mandriva.com.br> I have been having fun with controls. Today I tried to use the Pre-Read control together with the modify+increment extension, so that modify+increment becomes actually useful. I first added the encoding part to the ldap.so module, but later got a response from the pyasn1 mailing list and tried again in pure python. The result is attached. It's not complete yet, just a test. The script uses mod_increment to increment uidNumber and gidNumber by one. Attached to the modify operation is the preread control, so the response includes the value prior to the modification. Here is the output of two consecutive runs. Both attributes started at 1000 in LDAP: $ ./preread-asn1.py res: (103, [], 2, [PreReadControl(1.3.6.1.1.13.1,1.3.6.1.1.13.1,'0M\x04\x1fcn=unixIdPool,dc=example,dc=com0*0\x13\x04\tgidNumber1\x06\x04\x0410000\x13\x04\tuidNumber1\x06\x04\x041000')]) $ ./preread-asn1.py res: (103, [], 2, [PreReadControl(1.3.6.1.1.13.1,1.3.6.1.1.13.1,'0M\x04\x1fcn=unixIdPool,dc=example,dc=com0*0\x13\x04\tgidNumber1\x06\x04\x0410010\x13\x04\tuidNumber1\x06\x04\x041001')]) First one returns "1000", and the second one "1001" for both attributes. Now it's at 1002. The decoding part will probably be more difficult... As the control response is a SearchResultEntry which is a bit more complex to decode. -------------- next part -------------- #!/usr/bin/env python import ldap from pyasn1.type import univ from pyasn1.codec.der import encoder from ldap.controls import LDAPControl class LDAPString(univ.OctetString): pass class AttributeSelection(univ.SequenceOf): componentType = LDAPString("") class PreReadControl(LDAPControl): """ Pre-Read LDAP Control see RFC 4527 """ controlType = ldap.LDAP_CONTROL_PRE_READ def __init__(self, criticality, controlValue=None,encodedControlValue=None): LDAPControl.__init__(self, self.controlType, criticality, controlValue, encodedControlValue) def encodeControlValue(self, value): attributeSelection = AttributeSelection() for i in range(len(value)): attributeSelection.setComponentByPosition(i, value[i]) res = encoder.encode(attributeSelection) return res def decodeControlValue(self, value): # XXX return repr(value) uri = "ldap://localhost:389" base = "dc=example,dc=com" scope = ldap.SCOPE_SUBTREE filter = "(objectClass=sambaUnixIdPool)" ld = ldap.initialize(uri) ld.protocol_version = ldap.VERSION3 ld.bind_s("uid=LDAP Admin,ou=System Accounts,dc=example,dc=com", "ldapadmin") pr = PreReadControl(criticality=True, controlValue=['uidNumber','gidNumber']) modlist = [(ldap.MOD_INCREMENT, "uidNumber", "1"),(ldap.MOD_INCREMENT, "gidNumber", "1")] msg = ld.modify_ext("cn=unixIdPool,dc=example,dc=com", modlist, serverctrls = [pr]) res = ld.result3(msgid = msg, timeout = -1) print "res:", res # vim:ts=2:sw=2:et:ai:si From michael at stroeder.com Wed Jun 6 14:16:11 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 06 Jun 2007 14:16:11 +0200 Subject: Experiments with pyasn1 and preread control In-Reply-To: <20070605211241.GF25341@mandriva.com.br> References: <20070605211241.GF25341@mandriva.com.br> Message-ID: <4666A58B.3090602@stroeder.com> Andreas, Andreas Hasenack wrote: > I have been having fun with controls. Today I tried to use the Pre-Read > control together with the modify+increment extension, so that > modify+increment becomes actually useful. Thanks for sharing your experiences. > I first added the encoding part to the ldap.so module, but later got a > response from the pyasn1 mailing list and tried again in pure python. Saw your postings there. I'm also lurking on the pyasn1-users mailing list. The author seems to be quite responsive. > The decoding part will probably be more difficult... As the control > response is a SearchResultEntry which is a bit more complex to decode. How about exposing the function LDAPmessage_to_python() in message.c. It's used also to parse search results invoked by l_ldap_result3() in LDAPObject.c. Ciao, Michael. From ahasenack at terra.com.br Wed Jun 6 14:38:32 2007 From: ahasenack at terra.com.br (Andreas Hasenack) Date: Wed, 6 Jun 2007 09:38:32 -0300 Subject: Experiments with pyasn1 and preread control In-Reply-To: <4666A58B.3090602@stroeder.com> References: <20070605211241.GF25341@mandriva.com.br> <4666A58B.3090602@stroeder.com> Message-ID: <20070606123831.GA7000@mandriva.com.br> On Wed, Jun 06, 2007 at 02:16:11PM +0200, Michael Str?der wrote: > Andreas, > > Andreas Hasenack wrote: > > I have been having fun with controls. Today I tried to use the Pre-Read > > control together with the modify+increment extension, so that > > modify+increment becomes actually useful. > > Thanks for sharing your experiences. > > > I first added the encoding part to the ldap.so module, but later got a > > response from the pyasn1 mailing list and tried again in pure python. > > Saw your postings there. I'm also lurking on the pyasn1-users mailing > list. The author seems to be quite responsive. Yes he does > > The decoding part will probably be more difficult... As the control > > response is a SearchResultEntry which is a bit more complex to decode. > > How about exposing the function LDAPmessage_to_python() in message.c. > It's used also to parse search results invoked by l_ldap_result3() in > LDAPObject.c. Right. Later on I was thinking "but wait, python-ldap must already have such a function". I will check. Thanks From michael at stroeder.com Sat Jun 9 12:15:49 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Sat, 09 Jun 2007 12:15:49 +0200 Subject: [Fwd: Re: python-ldap for Python 2.5 on Windows?] Message-ID: <466A7DD5.2090607@stroeder.com> HI! Grabbed this posting from the Python newsgroup. I did not test this build yet and I don't know which features it supports. Ciao, Michael. -------- Original Message -------- Subject: Re: python-ldap for Python 2.5 on Windows? Date: Fri, 08 Jun 2007 10:23:09 -0700 From: Waldemar Osuch Organization: http://groups.google.com Newsgroups: comp.lang.python References: On Jun 8, 6:36 am, Benedict Verheyen wrote: > Hi, > > i found python-ldap for version Python 2.4. > Is there i place i can find a version for 2.5? > > If not, how can i build it myself for Windows? > I have managed to build it for myself using MinGW: http://www.osuch.org-a.googlepages.com/python-ldap-2.3.win32-py2.5.exe See if it will work for you Waldemar From ahasenack at terra.com.br Fri Jun 15 21:18:20 2007 From: ahasenack at terra.com.br (Andreas Hasenack) Date: Fri, 15 Jun 2007 16:18:20 -0300 Subject: [PATCH] RFC 3876 control (return values filter) In-Reply-To: <20070601142745.GA4388@mandriva.com.br> References: <20070601142745.GA4388@mandriva.com.br> Message-ID: <20070615191819.GB14212@mandriva.com.br> On Fri, Jun 01, 2007 at 11:27:45AM -0300, Andreas Hasenack wrote: > On Thu, May 31, 2007 at 07:23:36PM -0300, Andreas Hasenack wrote: > > I will still see about the decode part and then post what I have. > > Attached is my current patch. Keep in mind I did this basically using > the current code as a template. > > I ended up not implementing the decode part, I'm not sure for what it > would be needed. Just for completeness? No comments? Because of the missing decode part? From michael at stroeder.com Tue Jun 19 13:09:47 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 19 Jun 2007 13:09:47 +0200 Subject: CfP period for LDAPcon 2007 extended Message-ID: <4677B97B.4030004@stroeder.com> HI! again I would like to make readers of this list aware of LDAPcon 2007. Please see https://www.guug.de/veranstaltungen/ldapcon2007/index.html for details. The deadline for the CfP was extended to 2007-06-30. See https://www.guug.de/veranstaltungen/ldapcon2007/cfp.html for details if you'd like to submit a proposal for a presentation. Looking forward to meet you there. Ciao, Michael. From michael at stroeder.com Sat Jun 16 12:24:09 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Sat, 16 Jun 2007 12:24:09 +0200 Subject: [PATCH] RFC 3876 control (return values filter) In-Reply-To: <20070615191819.GB14212@mandriva.com.br> References: <20070601142745.GA4388@mandriva.com.br> <20070615191819.GB14212@mandriva.com.br> Message-ID: <4673BA49.8010609@stroeder.com> Andreas Hasenack wrote: > On Fri, Jun 01, 2007 at 11:27:45AM -0300, Andreas Hasenack wrote: >> On Thu, May 31, 2007 at 07:23:36PM -0300, Andreas Hasenack wrote: >>> I will still see about the decode part and then post what I have. >> Attached is my current patch. Keep in mind I did this basically using >> the current code as a template. >> >> I ended up not implementing the decode part, I'm not sure for what it >> would be needed. Just for completeness? > > No comments? Because of the missing decode part? Sorry, it's on my to-do list. Glancing over it I have no objections against the patch. I will try to commit it next week. Ciao, Michael. From ahasenack at terra.com.br Wed Jun 20 22:50:31 2007 From: ahasenack at terra.com.br (Andreas Hasenack) Date: Wed, 20 Jun 2007 17:50:31 -0300 Subject: Experiments with pyasn1 and preread control In-Reply-To: <4666A58B.3090602@stroeder.com> References: <20070605211241.GF25341@mandriva.com.br> <4666A58B.3090602@stroeder.com> Message-ID: <20070620205030.GC4414@mandriva.com.br> On Wed, Jun 06, 2007 at 02:16:11PM +0200, Michael Str?der wrote: > Andreas, > > Andreas Hasenack wrote: > > I have been having fun with controls. Today I tried to use the Pre-Read > > control together with the modify+increment extension, so that > > modify+increment becomes actually useful. > > Thanks for sharing your experiences. > > > I first added the encoding part to the ldap.so module, but later got a > > response from the pyasn1 mailing list and tried again in pure python. > > Saw your postings there. I'm also lurking on the pyasn1-users mailing > list. The author seems to be quite responsive. > > > > The decoding part will probably be more difficult... As the control > > response is a SearchResultEntry which is a bit more complex to decode. > > How about exposing the function LDAPmessage_to_python() in message.c. > It's used also to parse search results invoked by l_ldap_result3() in > LDAPObject.c. Hmm, the problem is that at that moment of decoding the control I don't have access to the LDAP* structure anymore, so I can't use LDAPmessage_to_python(). Or I'm missing something. All I have is the controlValue, which is an ldap message as returned by ldap_result which I would usually parse with ldap_first_message(3) and ldap_next_message(3). From roland.hedberg at adm.umu.se Mon Jun 25 20:33:34 2007 From: roland.hedberg at adm.umu.se (Roland Hedberg) Date: Mon, 25 Jun 2007 20:33:34 +0200 Subject: subtree move Message-ID: <46800A7E.6090709@adm.umu.se> Hi! It seems like Python-ldap does not support modifyDN. That is moving a subtree from one place on a server to another place on the same server. So, has anyone implemented modifyDN on top of python-ldap ? I realize it will not be very efficient, but then the subtree I might have to move is only one level deep and with a limited set of entries. -- Roland From michael at stroeder.com Mon Jun 25 22:31:19 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 25 Jun 2007 22:31:19 +0200 Subject: subtree move In-Reply-To: <46800A7E.6090709@adm.umu.se> References: <46800A7E.6090709@adm.umu.se> Message-ID: <46802617.9040404@stroeder.com> Roland Hedberg wrote: > > It seems like Python-ldap does not support modifyDN. That is moving a > subtree from one place on a server to another place on the same server. See methods rename() and rename_s() with argument newsuperior. You can rename a sub-tree with e.g. with OpenLDAP/back-hdb. > So, has anyone implemented modifyDN on top of python-ldap ? > > I realize it will not be very efficient, but then the subtree I might > have to move is only one level deep and with a limited set of entries. Or are you talking about moving sub-trees in case the LDAP server does not support sub-tree renaming? I have something slightly more efficient based on evaluating hasSubordinates or similar attributes for sub-tree deletion in web2ldap. Ciao, Michael. From roland.hedberg at adm.umu.se Tue Jun 26 09:04:05 2007 From: roland.hedberg at adm.umu.se (Roland Hedberg) Date: Tue, 26 Jun 2007 09:04:05 +0200 Subject: subtree move In-Reply-To: <46802617.9040404@stroeder.com> References: <46800A7E.6090709@adm.umu.se> <46802617.9040404@stroeder.com> Message-ID: <4680BA65.5070004@adm.umu.se> Michael Str?der wrote: > Roland Hedberg wrote: >> So, has anyone implemented modifyDN on top of python-ldap ? > > Or are you talking about moving sub-trees in case the LDAP server does > not support sub-tree renaming? Yes, I can make no assumptions as to what the server can or can't. > I have something slightly more efficient based on evaluating > hasSubordinates or similar attributes for sub-tree deletion in web2ldap. If you are willing to share I'd love to have it :-) -- Roland From michael at stroeder.com Tue Jun 26 09:37:36 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 26 Jun 2007 09:37:36 +0200 Subject: subtree move In-Reply-To: <4680BA65.5070004@adm.umu.se> References: <46800A7E.6090709@adm.umu.se> <46802617.9040404@stroeder.com> <4680BA65.5070004@adm.umu.se> Message-ID: <4680C240.8010600@stroeder.com> Roland Hedberg wrote: >> I have something slightly more efficient based on evaluating >> hasSubordinates or similar attributes for sub-tree deletion in web2ldap. > > If you are willing to share I'd love to have it :-) Hmm, look into web2ldap's source (GPL): function DelTree() in pylib/w2lapp/delete.py. But it's not in a shape to directly use it. It's more munged into the application. And the hasSubordinates handling is slightly different from what you need. It rather trys to delete a whole entry and retries differently after receiving ldap.NOT_ALLOWED_ON_NONLEAF. Hmm, glancing over the code I'd suggest to implement it separately. I'd try to rename the whole sub-tree first and then handle ldap.NOT_ALLOWED_ON_NONLEAF smoothly. Ciao, Michael. From roland.hedberg at adm.umu.se Tue Jun 26 21:19:09 2007 From: roland.hedberg at adm.umu.se (Roland Hedberg) Date: Tue, 26 Jun 2007 21:19:09 +0200 Subject: subtree move In-Reply-To: <4680C240.8010600@stroeder.com> References: <46800A7E.6090709@adm.umu.se> <46802617.9040404@stroeder.com> <4680BA65.5070004@adm.umu.se> <4680C240.8010600@stroeder.com> Message-ID: <468166AD.9030906@adm.umu.se> Michael Str?der wrote: > Hmm, glancing over the code I'd suggest to implement it separately. I'd > try to rename the whole sub-tree first and then handle > ldap.NOT_ALLOWED_ON_NONLEAF smoothly. That was my intention. -- Roland From python-ldap at tk-webart.de Fri Jun 29 14:28:27 2007 From: python-ldap at tk-webart.de (Torsten Kurbad) Date: Fri, 29 Jun 2007 14:28:27 +0200 Subject: python-ldap on PyPI Message-ID: <4684FAEB.5040609@tk-webart.de> Hi there, I'm currently involved in a project, using Zope3, there we would need a proper python-ldap.egg from the Python Cheeseshop. I realized that someone checked in some specs there (http://www.python.org/pypi/python-ldap/2.0.11), but there's no .egg file attached to this record - therefore my project fails to build. So my question is twofold: a) Who maintains the PyPI entries of python-ldap? Is it actively maintained in general? b) If not, how can I help to get it done? Best regards, Torsten From michael at stroeder.com Fri Jun 29 15:34:13 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 29 Jun 2007 15:34:13 +0200 Subject: python-ldap on PyPI In-Reply-To: <4684FAEB.5040609@tk-webart.de> References: <4684FAEB.5040609@tk-webart.de> Message-ID: <46850A55.8090508@stroeder.com> Torsten Kurbad wrote: > > I'm currently involved in a project, using Zope3, there we would need a > proper python-ldap.egg from the Python Cheeseshop. I realized that > someone checked in some specs there > (http://www.python.org/pypi/python-ldap/2.0.11), but there's no .egg > file attached to this record - therefore my project fails to build. > > So my question is twofold: > a) Who maintains the PyPI entries of python-ldap? Is it actively > maintained in general? > b) If not, how can I help to get it done? Since I never looked into .egg files I'd appreciate if you could provide one and I do the rest of putting it on PyPI. Ciao, Michael.