From python3ldap at gmail.com Mon Jan 5 22:13:08 2015 From: python3ldap at gmail.com (python3ldap) Date: Mon, 5 Jan 2015 22:13:08 +0100 Subject: [python3-ldap] Project name change: python3-ldap is now ldap3 Message-ID: Hello everybody, I've changed the name of the python3-ldap project to ldap3, the same name of the importing package, as suggested in the Package User Guide (https://packaging.python.org/en/latest/index.html) by the Python Packaging Authority. Hope this will help to avoid confusion with the former python-ldap package. Also, I've moved to GitHub (https://github.com/cannatag/ldap3) and I've set up a cloud lab where tests are automatically performed with Travis-CI (https://travis-ci.org/cannatag/ldap3). Documentation is now automaticallyh builded and hosted at https://ldap3.readthedocs.org. Tests are performed with Python 2.6, Python 2.7, Python 3.4, PyPy 2,4 and PyPy3 2.4. Previous bugs on BitBucket are closed. Bugs and suggestions can be submitted with the new tracker at https://github.com/cannatag/ldap3/issues/new. Python3-ldap 0.9.7 will remain on pypi for some time. Develop will proceed only on GitHub and new release will be available with the ldap3 project at https://pypi.python.org/pypi/ldap3 I've released v 0.9.7.1 of ldap3. This release has two major changes: the test suite is fully refactored to be used on Travis-CI with some ldap servers hosted in the cloud (eDirectory, Active Directory and OpenLDAP). The other change regards the constants defined in the ldap3 namespace. I've changed the constants values from int to a more descriptive string, This should not be a problem if you use the constant names and not its value (as it should be if you import them the ldap3 package), and it's quite helpful while debugging. This is the changelog for the 0.9.7.1 release of ldap3. * 0.9.7.1 2015.01.05 - Moved to Github - Moved to Travis-CI for continuous integration - Moved to ReadTheDocs for documentation - Moved testing servers in the cloud, to allow testing from Travis-CI - Project renamed from python3-ldap to ldap3 to avoid name clashing with the existing python-ldap library - Constant values in ldap3 are now strings. This is helpful in testing and debugging - Test suite fully refactored to be used in cloud lab and local development lab - Test suite includes options for testing against eDirectory, Active Directory and OpenLDAP Bye, Giovanni Cannata From python3ldap at gmail.com Tue Feb 3 08:17:06 2015 From: python3ldap at gmail.com (python3ldap) Date: Tue, 3 Feb 2015 08:17:06 +0100 Subject: [python3-ldap] ldap3 0.9.7.4 released Message-ID: Hello everyody, I've released the 0.9.7.4 version of ldap3 (formerly python3-ldap). In this mior release I've added the "entries" property to the connection object. It is populated after a search operation (and only if you explicitly access it) with a more abstract representation of the search response. It uses the Entry object from the abstract package and gives you a fast and more pythonic way of getting and using the entries returned by a search operation: For example: c.search('o=test','(objectClass=*)', SUBTREE, attributes = ['sn', 'givenName', 'objectClass'], get_operational_attributes = True) for entry in c.entries: print(entry.entry_get_dn()) print(entry.givenName, entry.sn) The Entry object is read only (you can't assign any attribute to it, just read their values) and has a dual nature, it can be used as a dictionary (entry['givenName']) and as a namespace (entry.givenname). The keys are always case-insensitive. You can easily get the value (with entry.value or entry.values) (already formatted if you read the schema in the Server object) and the raw (binary) value (with entry.raw_values). You can easily convert to ldif or json with the entry_to_ldif() and entry_to_json() methods. I've found this very helpful at the interactive prompt where you can get a pretty print of the entries with its __repr__ method: >>> c.entries[0] DN: o=services ACL: 2#entry#o=services#loginScript 2#entry#o=services#printJobConfiguration 32#subtree#cn=edir1,o=services#[All Attributes Rights] 16#subtree#cn=edir1,o=services#[Entry Rights] 32#subtree#cn=edir2,o=services#[All Attributes Rights] 16#subtree#cn=edir2,o=services#[Entry Rights] 32#subtree#cn=edir3,o=services#[All Attributes Rights] 16#subtree#cn=edir3,o=services#[Entry Rights] GUID: fd9a0d90-15be-2841-fd82-fd9a0d9015be backLink: 32860#cn=edir3,o=services createTimestamp: 2014-06-20 13:19:14+00:00 entryDN: o=services entryFlags: 4 localEntryID: 32787 modifiersName: cn=admin,o=services modifyTimestamp: 2014-11-07 08:17:43+00:00 name: services o: services objectClass: Organization ndsLoginProperties ndsContainerLoginProperties Top revision: 6 structuralObjectClass: Organization subordinateCount: 33 subschemaSubentry: cn=schema Entry has a few additional methods to get the attributes names, and the raw_values of all attributes. Look at the abstraction layer documentation for more info. This version includes the following fixes: 0.9.7.4 2015.02.02 Added connection.entries property for storing response from search operations as and abstract.Entry collection. 0.9.7.3 2015.01.25 Modify operation type can also be passed as integer 0.9.7.2 2015.01.16 Fixed a bug when resolving IP address with getaddrinfo(). On OSX returned an UDP connection. Bye, Giovanni From mward at cims.nyu.edu Wed Feb 18 22:23:16 2015 From: mward at cims.nyu.edu (Michael Ward) Date: Wed, 18 Feb 2015 16:23:16 -0500 Subject: [python3-ldap] Submit LDIF data for processing via ldap3 Message-ID: Really digging this project so far. Just a quick question: I noticed that it's possible to turn an ldap3 LDAP operation into an LDIF format (either with response_to_ldif(results) for CONTENT or an LDIF connection strategy for CHANGE), but is it possible to go the other way around? i.e. I have an LDIF change record in plain text --- can I feed that into ldap3 somehow to perform the corresponding LDAP operation? I read the docs and I don't think this is possible, but I just want to double check. Thanks! Mike From cannatag at gmail.com Wed Feb 18 23:22:22 2015 From: cannatag at gmail.com (Giovanni Cannata) Date: Wed, 18 Feb 2015 23:22:22 +0100 Subject: [python3-ldap] Submit LDIF data for processing via ldap3 In-Reply-To: References: Message-ID: Hello Michael, converting an LDIF-CHANGE to an operation is a feature not provided by the ldap3 library, but it should be easy to develop. Can I ask why you need that? Keep in mind that LDIF-CHANGE is related to LDAP server operations, not client's, and usually you already have some server utilities to do that. Bye, Giovanni 2015-02-18 22:23 GMT+01:00 Michael Ward : > Really digging this project so far. Just a quick question: > > I noticed that it's possible to turn an ldap3 LDAP operation into an LDIF > format (either with response_to_ldif(results) for CONTENT or an LDIF > connection strategy for CHANGE), but is it possible to go the other way > around? i.e. I have an LDIF change record in plain text --- can I feed > that into ldap3 somehow to perform the corresponding LDAP operation? I > read the docs and I don't think this is possible, but I just want to > double check. > > Thanks! > Mike > > _______________________________________________ > python3-ldap mailing list > python3-ldap at python.org > https://mail.python.org/mailman/listinfo/python3-ldap From mward at cims.nyu.edu Wed Feb 18 23:55:39 2015 From: mward at cims.nyu.edu (Michael Ward) Date: Wed, 18 Feb 2015 17:55:39 -0500 Subject: [python3-ldap] Submit LDIF data for processing via ldap3 In-Reply-To: References: Message-ID: <66c64658fe7b37d250042df971fd8a21.squirrel@webmail.cims.nyu.edu> Thanks Giovanni! Yes, you're exactly right --- we already have the standard "ldapadd" and "ldapmodify" utilities that can accomplish LDIF processing, I was just wondering if there was some way to use ldap3 instead, that way we can keep all of our LDAP tools in one place and in Python. My interest in this function is that, for example, when we expire user accounts, we keep archive their LDAP records as LDIF files. In some cases an expired user returns and needs their account reopened, and we need to recreate their accounts as they existed when they were expired. It would be cool if I could just feed the old LDIF records into ldap3 and say "re-create these records." I write everything in Python, and when I write a script like unexpire-user.py, I was just wondering if I could do these operations in native Python with ldap3. But for now I can just make shell calls to /usr/bin/ldapadd and pass it the LDIF filename. Thanks for your prompt response. Mike On Wed, February 18, 2015 17:22, Giovanni Cannata wrote: > Hello Michael, > converting an LDIF-CHANGE to an operation is a feature not provided by > the ldap3 library, but it should be easy to develop. > > Can I ask why you need that? Keep in mind that LDIF-CHANGE is related > to LDAP server operations, not client's, and usually you already have > some server utilities to do that. > > Bye, > Giovanni > > > 2015-02-18 22:23 GMT+01:00 Michael Ward : >> Really digging this project so far. Just a quick question: >> >> I noticed that it's possible to turn an ldap3 LDAP operation into an >> LDIF >> format (either with response_to_ldif(results) for CONTENT or an LDIF >> connection strategy for CHANGE), but is it possible to go the other way >> around? i.e. I have an LDIF change record in plain text --- can I feed >> that into ldap3 somehow to perform the corresponding LDAP operation? I >> read the docs and I don't think this is possible, but I just want to >> double check. >> >> Thanks! >> Mike >> >> _______________________________________________ >> python3-ldap mailing list >> python3-ldap at python.org >> https://mail.python.org/mailman/listinfo/python3-ldap > From cannatag at gmail.com Thu Feb 19 23:40:10 2015 From: cannatag at gmail.com (Giovanni Cannata) Date: Thu, 19 Feb 2015 23:40:10 +0100 Subject: [python3-ldap] Submit LDIF data for processing via ldap3 In-Reply-To: <66c64658fe7b37d250042df971fd8a21.squirrel@webmail.cims.nyu.edu> References: <66c64658fe7b37d250042df971fd8a21.squirrel@webmail.cims.nyu.edu> Message-ID: Hi Mike, so you need a way to read a LDIF-CONTENT stream and get it back as a sequence of LDAP add or modify operations. The problem with this feature is that when you are reading the stream of LDIF-CONTENT there could be some "forward reference" to a not still existing object that is ahead in the stream (for example membership to a group not yet defined). For this reason LDAP servers "relax" their controls while importing an LDIF-CONTENT until the end of the stream, to see if "forward references are resolved. I think that this can be accomplished in the ldap3 client library carefully preloading the LDIF-CONTENT stream to give priority to referenced objects, I will try to define a utility function to do this in the next few weeks. To have a working LDIF import feature I think that there should be a way to "reverse" LDIF-CHANGE too in the library, so I will work on both. Bye, Giovanni 2015-02-18 23:55 GMT+01:00 Michael Ward : > Thanks Giovanni! Yes, you're exactly right --- we already have the > standard "ldapadd" and "ldapmodify" utilities that can accomplish LDIF > processing, I was just wondering if there was some way to use ldap3 > instead, that way we can keep all of our LDAP tools in one place and in > Python. > > My interest in this function is that, for example, when we expire user > accounts, we keep archive their LDAP records as LDIF files. In some cases > an expired user returns and needs their account reopened, and we need to > recreate their accounts as they existed when they were expired. It would > be cool if I could just feed the old LDIF records into ldap3 and say > "re-create these records." I write everything in Python, and when I write > a script like unexpire-user.py, I was just wondering if I could do these > operations in native Python with ldap3. But for now I can just make shell > calls to /usr/bin/ldapadd and pass it the LDIF filename. > > Thanks for your prompt response. > > Mike > > On Wed, February 18, 2015 17:22, Giovanni Cannata wrote: >> Hello Michael, >> converting an LDIF-CHANGE to an operation is a feature not provided by >> the ldap3 library, but it should be easy to develop. >> >> Can I ask why you need that? Keep in mind that LDIF-CHANGE is related >> to LDAP server operations, not client's, and usually you already have >> some server utilities to do that. >> >> Bye, >> Giovanni >> >> >> 2015-02-18 22:23 GMT+01:00 Michael Ward : >>> Really digging this project so far. Just a quick question: >>> >>> I noticed that it's possible to turn an ldap3 LDAP operation into an >>> LDIF >>> format (either with response_to_ldif(results) for CONTENT or an LDIF >>> connection strategy for CHANGE), but is it possible to go the other way >>> around? i.e. I have an LDIF change record in plain text --- can I feed >>> that into ldap3 somehow to perform the corresponding LDAP operation? I >>> read the docs and I don't think this is possible, but I just want to >>> double check. >>> >>> Thanks! >>> Mike >>> >>> _______________________________________________ >>> python3-ldap mailing list >>> python3-ldap at python.org >>> https://mail.python.org/mailman/listinfo/python3-ldap >> > > From cannatag at gmail.com Sat Feb 21 08:06:49 2015 From: cannatag at gmail.com (Giovanni Cannata) Date: Sat, 21 Feb 2015 08:06:49 +0100 Subject: [python3-ldap] sldap3 0.9.7.5 released Message-ID: Hello everybody, I've release the 0.9.7.5 version of ldap3. Just minor fixes here: * 0.9.7.5 2015.02.20 - Fixed exception raised when opening a connection to a server. If there is only one candidate address and there is an error it returns the specific Exception, not a generic LDAPException error - Address_info filters out any impossible address to reach - Address_info include an IPV4MAPPED address for IPV6 host that try to reach an IPV4 only server - Added SyncMock strategy (needs the sldap3 package) - Fixed bug when using the aproximation operation in ldap search operations (thanks Laurent) - Removed response from exception raised with raise_exceptions=True to avoid very long exceptions message * 0.9.7.4 2015.02.02 - Added connection.entries property for storing response from search operations as and abstract.Entry collection. * 0.9.7.3 2015.01.25 - Modify operation type can also be passed as integer * 0.9.7.2 2015.01.16 - Fixed a bug when resolving IP address with getaddrinfo(). On OSX returned an UDP connection (thanks Hiroshi). Bye, Giovanni From cannatag at gmail.com Sat Feb 28 09:11:26 2015 From: cannatag at gmail.com (Giovanni Cannata) Date: Sat, 28 Feb 2015 09:11:26 +0100 Subject: [python3-ldap] ldap3 version bumped to 0.9.7.10 Message-ID: Hi, I had to bump the version of ldap3 to 0.9.7.10 for incompatibilites with the new stricter rules used by Pypi following PEP 440 (Version Identification and Dependency Specification). There is only a minor fix in this release: an exception was raised if a paged search excedeed the hard size limit set on the LDAP server. Now it works as expected, returning only the entries returned in the responses from the server. Bye, Giovanni From derrick.jackson73 at gmail.com Wed Mar 11 16:07:33 2015 From: derrick.jackson73 at gmail.com (Derrick Jackson) Date: Wed, 11 Mar 2015 11:07:33 -0400 Subject: [python3-ldap] Connection Slowness Message-ID: Hi all, I am trying to understand why connections (authentication and searching) are so much slower using python3-ldap with python 3.4 vs python-ldap with python 2.7. Has anyone else noticed a difference? -------------- next part -------------- An HTML attachment was scrubbed... URL: From python3ldap at gmail.com Wed Mar 11 16:38:58 2015 From: python3ldap at gmail.com (Python3-ldap) Date: Wed, 11 Mar 2015 16:38:58 +0100 Subject: [python3-ldap] R: Connection Slowness In-Reply-To: References: Message-ID: <5500619d.4160b40a.2419.ffffe269@mx.google.com> Hi Derrick, what do you mean with "so much slower"? ldap3 is a pure python library, not a wrapper around openldap C libraries, so it is intrinsically slower than python-ldap. But in my usage I notice the difference only with very long searches, not with authentication (even during authentication there may be a search operation if you read the schema of your ldap server). Slow connection can also be generated by wrong dns resolution. Anyway, are you using the latest ldap3 (not python3-ldap) package? Bye, Giovanni ----- Messaggio originale ----- Da: "Derrick Jackson" Inviato: ?11/?03/?2015 16:08 A: "python3-ldap at python.org" Oggetto: [python3-ldap] Connection Slowness Hi all, I am trying to understand why connections (authentication and searching) are so much slower using python3-ldap with python 3.4 vs python-ldap with python 2.7. Has anyone else noticed a difference? -------------- next part -------------- An HTML attachment was scrubbed... URL: From derrick.jackson73 at gmail.com Wed Mar 11 18:05:43 2015 From: derrick.jackson73 at gmail.com (Derrick Jackson) Date: Wed, 11 Mar 2015 13:05:43 -0400 Subject: [python3-ldap] Connection Slowness In-Reply-To: <5500619d.4160b40a.2419.ffffe269@mx.google.com> References: <5500619d.4160b40a.2419.ffffe269@mx.google.com> Message-ID: Hi Giovanni, Thanks for the quick follow-up. I was up until a moment ago using python3-ldap. I am using ldap3 now. However I am still finding that authentication and search are taking a bit longer to respond. Here is the flow I am following. 1. User hits the login page and sends credentials and enters their email address and password. 2. A generic account logs into Active Directory and searches for that user. If found, that user's information is returned and the connection is closed. 3. We then create another connection and authenticate the user based on the username returned from step2. Once authenticated the user is allowed access to the application. 4. This process takes ~16-25 seconds to complete. I decided to test this outside of my web application so i went to the python interpreter, imported ldap3 and did the following: AD_URL = 'host:636' PORT = 636 s = Server(AD_URL, get_info=None, use_ssl=True) c = Connection(s, auto_bind=True, user='domain\username', password=password) This process took about 6 seconds to complete. I am trying to understand where the choke point is right now. Just wondering if it is our ldap server or something else. On Wed, Mar 11, 2015 at 11:38 AM, Python3-ldap wrote: > Hi Derrick, > what do you mean with "so much slower"? ldap3 is a pure python library, > not a wrapper around openldap C libraries, so it is intrinsically slower > than python-ldap. But in my usage I notice the difference only with very > long searches, not with authentication (even during authentication there > may be a search operation if you read the schema of your ldap server). Slow > connection can also be generated by wrong dns resolution. Anyway, are you > using the latest ldap3 (not python3-ldap) package? > > Bye, > Giovanni > ------------------------------ > Da: Derrick Jackson > Inviato: ?11/?03/?2015 16:08 > A: python3-ldap at python.org > Oggetto: [python3-ldap] Connection Slowness > > Hi all, > > I am trying to understand why connections (authentication and searching) > are so much slower using python3-ldap with python 3.4 vs python-ldap with > python 2.7. Has anyone else noticed a difference? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mr.gary.waters at gmail.com Wed Mar 11 19:17:05 2015 From: mr.gary.waters at gmail.com (Gary Waters) Date: Wed, 11 Mar 2015 11:17:05 -0700 Subject: [python3-ldap] Connection Slowness In-Reply-To: References: <5500619d.4160b40a.2419.ffffe269@mx.google.com> Message-ID: <550086A1.8030105@gmail.com> I am curious. Can you try port 389 and binding as annonymous in the python interpreter as a quick test? How long does that take. -Gary On 03/11/2015 10:05 AM, Derrick Jackson wrote: > Hi Giovanni, > > Thanks for the quick follow-up. I was up until a moment ago using > python3-ldap. I am using ldap3 now. However I am still finding that > authentication and search are taking a bit longer to respond. Here is > the flow I am following. > > 1. User hits the login page and sends credentials and enters their > email address and password. > 2. A generic account logs into Active Directory and searches for that > user. If found, that user's information is returned and the connection > is closed. > 3. We then create another connection and authenticate the user based on > the username returned from step2. Once authenticated the user is > allowed access to the application. > 4. This process takes ~16-25 seconds to complete. > > I decided to test this outside of my web application so i went to the > python interpreter, imported ldap3 and did the following: > > AD_URL = 'host:636' > PORT = 636 > > s = Server(AD_URL, get_info=None, use_ssl=True) > c = Connection(s, auto_bind=True, user='domain\username', password=password) > > This process took about 6 seconds to complete. I am trying to > understand where the choke point is right now. Just wondering if it is > our ldap server or something else. > > On Wed, Mar 11, 2015 at 11:38 AM, Python3-ldap > wrote: > > Hi Derrick, > what do you mean with "so much slower"? ldap3 is a pure python > library, not a wrapper around openldap C libraries, so it is > intrinsically slower than python-ldap. But in my usage I notice the > difference only with very long searches, not with authentication > (even during authentication there may be a search operation if you > read the schema of your ldap server). Slow connection can also be > generated by wrong dns resolution. Anyway, are you using the latest > ldap3 (not python3-ldap) package? > > Bye, > Giovanni > ------------------------------------------------------------------------ > Da: Derrick Jackson > Inviato: ?11/?03/?2015 16:08 > A: python3-ldap at python.org > Oggetto: [python3-ldap] Connection Slowness > > Hi all, > > I am trying to understand why connections (authentication and > searching) are so much slower using python3-ldap with python 3.4 vs > python-ldap with python 2.7. Has anyone else noticed a difference? > > > > > _______________________________________________ > python3-ldap mailing list > python3-ldap at python.org > https://mail.python.org/mailman/listinfo/python3-ldap > From derrick.jackson73 at gmail.com Wed Mar 11 20:15:06 2015 From: derrick.jackson73 at gmail.com (Derrick Jackson) Date: Wed, 11 Mar 2015 15:15:06 -0400 Subject: [python3-ldap] Connection Slowness In-Reply-To: <550086A1.8030105@gmail.com> References: <5500619d.4160b40a.2419.ffffe269@mx.google.com> <550086A1.8030105@gmail.com> Message-ID: Hi Gary, Changing my AD_URL to the non-ssl and updating the port as you requested still took approximately 6 seconds to receive a response. We do have python 2.7 webapps using that AD_URL over SSL and the response time is extremely fast. On Wed, Mar 11, 2015 at 2:17 PM, Gary Waters wrote: > I am curious. Can you try port 389 and binding as annonymous in the python > interpreter as a quick test? How long does that take. > > -Gary > > > On 03/11/2015 10:05 AM, Derrick Jackson wrote: > >> Hi Giovanni, >> >> Thanks for the quick follow-up. I was up until a moment ago using >> python3-ldap. I am using ldap3 now. However I am still finding that >> authentication and search are taking a bit longer to respond. Here is >> the flow I am following. >> >> 1. User hits the login page and sends credentials and enters their >> email address and password. >> 2. A generic account logs into Active Directory and searches for that >> user. If found, that user's information is returned and the connection >> is closed. >> 3. We then create another connection and authenticate the user based on >> the username returned from step2. Once authenticated the user is >> allowed access to the application. >> 4. This process takes ~16-25 seconds to complete. >> >> I decided to test this outside of my web application so i went to the >> python interpreter, imported ldap3 and did the following: >> >> AD_URL = 'host:636' >> PORT = 636 >> >> s = Server(AD_URL, get_info=None, use_ssl=True) >> c = Connection(s, auto_bind=True, user='domain\username', >> password=password) >> >> This process took about 6 seconds to complete. I am trying to >> understand where the choke point is right now. Just wondering if it is >> our ldap server or something else. >> >> On Wed, Mar 11, 2015 at 11:38 AM, Python3-ldap > > wrote: >> >> Hi Derrick, >> what do you mean with "so much slower"? ldap3 is a pure python >> library, not a wrapper around openldap C libraries, so it is >> intrinsically slower than python-ldap. But in my usage I notice the >> difference only with very long searches, not with authentication >> (even during authentication there may be a search operation if you >> read the schema of your ldap server). Slow connection can also be >> generated by wrong dns resolution. Anyway, are you using the latest >> ldap3 (not python3-ldap) package? >> >> Bye, >> Giovanni >> ------------------------------------------------------------ >> ------------ >> Da: Derrick Jackson >> Inviato: ?11/?03/?2015 16:08 >> A: python3-ldap at python.org >> Oggetto: [python3-ldap] Connection Slowness >> >> Hi all, >> >> I am trying to understand why connections (authentication and >> searching) are so much slower using python3-ldap with python 3.4 vs >> python-ldap with python 2.7. Has anyone else noticed a difference? >> >> >> >> >> _______________________________________________ >> python3-ldap mailing list >> python3-ldap at python.org >> https://mail.python.org/mailman/listinfo/python3-ldap >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From damiano.scrigni at badbit.it Thu Mar 12 12:47:56 2015 From: damiano.scrigni at badbit.it (Damiano Scrigni) Date: Thu, 12 Mar 2015 11:47:56 +0000 Subject: [python3-ldap] Problem retrieving UUID Message-ID: Hello everyone, Does anyone has this problem when retrieving an UUID attribute? lib\site-packages\ldap3\protocol\formatters\formatters.py", line 64, in format_uuid return str(UUID(bytes=raw_value)) File "C:\Python34\Lib\uuid.py", line 148, in __init__ raise ValueError('bytes is not a 16-char string') ValueError: bytes is not a 16-char string I have found that changing line 64 in ldap3\protocol\formatters\formatters.py from: return str(UUID(bytes=raw_value)) to: return str(UUID(raw_value.decode("ASCII"))) solves the problem, but I have no idea about the side effects of the change. Bye, damiano From cannatag at gmail.com Sun Apr 5 00:01:07 2015 From: cannatag at gmail.com (Giovanni Cannata) Date: Sun, 5 Apr 2015 00:01:07 +0200 Subject: [python3-ldap] ldap3 version 0.9.8.1 released Message-ID: Hello everybody, I've released the 0.9.8.1 version of ldap3. This release supports NTLMv2 authentication to Active Directory. It uses a non-standard protocol from Microsoft named Sicily that encapsulates the NTLM message in the bindRequest and bindResponse. It doesn't follow the LDAP RFCs and breaks a few rules of LDAP protocol itself, but should not have any side effect on the standard bind operation. There is no additional package to import, the ldap.utils.ntlm module is pure python and should work with Python 2 and Python 3. To use the new authentcation method you must set the authentication parameter to NTLM and pass the domainname\username value for the user name while defining the connection: Example: from ldap3 import Server, Connection, NTLM s = Server('win1') c = Connection(s, user='MYDOMAIN\MyUser', password='mypassword', authentication=NTLM) c.bind() #other ldap operations c.unbind() I've developed the ldap3.utils.ntlm package following the official microsoft documentation at https://msdn.microsoft.com/en-us/library/cc236621.aspx and tested against a Microsoft WIndows Server 2012 R2, Because I have no easy access to other versions Active Directory servers let me know if this works for you. Thanks, Giovanni From cannatag at gmail.com Mon Apr 20 18:01:46 2015 From: cannatag at gmail.com (Giovanni Cannata) Date: Mon, 20 Apr 2015 18:01:46 +0200 Subject: [python3-ldap] sldap3 project - A pure Python LDAP server Message-ID: Hello everybody, I'm starting a new open source project based on the ldap3 package. The project is named sldap3 and is still at alpha developing stage. My idea is to have build an LDAPv3 server based reusing the protocol component of the ldap3 package and the new asyncio network communication package of Python 3 (backported to python 2 via the Trollius package). The server should be able to run multiple LDAP services (cleartext of tls secured) on a single instance using event loops (either in threads or in processes), using different backends for the data component and the user component. For example it should be possible to store the authentication information in a json file and the data in a postgresql database. Project requisites: - pure Python - compatible with Python 3 and Python 2, PyPy - run as a service in Windows and as a daemon in Linux - usage of asyncio network communication Project wishlist: - multi instance (in threads or processes) - multiple backend for user authentication - multiple backend for data storage - multiple backend for schema definition - data replication (maybe) This project should be helpful for testing ldap applications in a simple way, having an effective ldap server with easy and replicable configuration. It could also be used is projects that needs a simple ldap server for authentication and data storage. You can see a pre-pre-pre alpha version (only DSA definition and simple bind are working) at https://github.com/cannatag/sldap3/tree/dev This is the dev branch and I'm still working on the core component so please don't expect it works seamlessy... Do you have any additional idea to be included in the requisites or in the wishlist? Let me know what you think (esplecially if you think this is silly and a waste of time...) Bye, Giovanni From cannatag at gmail.com Mon May 11 17:44:12 2015 From: cannatag at gmail.com (Giovanni Cannata) Date: Mon, 11 May 2015 17:44:12 +0200 Subject: [python3-ldap] ldap3 0.9.8.3 released Message-ID: Hello, I've release ldap3 0.9.8.3. It has two major features (extensive logging and kerberos authentication) and a bunch of fixes: This is the changelog: * 0.9.8.3 2015.05.11 - Added support for logging - Added LDAPInvalidTlsSpecificationError exception - Added support for kerberos sasl - needs the gssapi package (thanks sigmaris and pefoley2) - Added support for using generator objects in ldap operations (thanks Matt) - Fixed bug in collect_usage (thanks Philippe) - Changed default server mode from IP_SYSTEM_DEFAULT to IP_V6_PREFERRED There is a change in the default server mode to follow what most dual stack libraries do, trying first IPv6 addresses and then IPv4. You can override this behaviour with the mode parameter in the server object. I've limited access to kerberos platforms, so I really didn't check the SASL kerberos authentication mechanism. Open an issue on github if you have problem with this feature. The logging feature is quite impresive (at least to me). It logs everything at different "layers": at the library machinery level (BASIC), at the protocol level (PROTOCOL) and at the socket (NETWORK) level. Please check the docs at http://ldap3.readthedocs.org/logging.html. This is an example of what you can get at the maximum detail level (NETWORK) for a search (over an SSL connection with simple bind) that returns a few objects: : INFO:ldap3:ldap3 library initialized - logging emitted with loglevel set to DEBUG - available detail levels are: OFF, ERROR, BASIC, PROTOCOL, NETWORK DEBUG:ldap3:ERROR:detail level set to NETWORK DEBUG:ldap3:BASIC:instantiated Tls: DEBUG:ldap3:BASIC:instantiated Server: DEBUG:ldap3:BASIC:instantiated Usage object DEBUG:ldap3:BASIC:instantiated : DEBUG:ldap3:BASIC:instantiated Connection: DEBUG:ldap3:BASIC:start BIND operation via DEBUG:ldap3:NETWORK:opening connection for DEBUG:ldap3:BASIC:reset usage metrics DEBUG:ldap3:BASIC:start collecting usage metrics DEBUG:ldap3:BASIC:address for resolved at <[, , 6, '', ('192.168.137.101', 636)]> DEBUG:ldap3:BASIC:candidate address for : <[, , 6, '', ('192.168.137.101', 636)]> DEBUG:ldap3:NETWORK:socket wrapped with SSL using SSLContext for DEBUG:ldap3:NETWORK:connection open for DEBUG:ldap3:PROTOCOL:performing simple BIND for DEBUG:ldap3:PROTOCOL:simple BIND request <{'version': 3, 'authentication': {'simple': 'password', 'sasl': None}, 'name': 'cn=admin,o=services'}> sent via DEBUG:ldap3:PROTOCOL:new message id <1> generated DEBUG:ldap3:NETWORK:sending message for DEBUG:ldap3:NETWORK:sent 41 bytes via DEBUG:ldap3:NETWORK:received 14 bytes via DEBUG:ldap3:NETWORK:received 1 ldap messages via DEBUG:ldap3:PROTOCOL:BIND response <{'type': 'bindResponse', 'referrals': None, 'dn': '', 'result': 0, 'description': 'success', 'saslCreds': None, 'message': ''}> received via DEBUG:ldap3:BASIC:refreshing server info for DEBUG:ldap3:BASIC:done BIND operation, result DEBUG:ldap3:BASIC:start SEARCH operation via DEBUG:ldap3:PROTOCOL:SEARCH request <{'attributes': ['objectClass', 'sn'], 'timeLimit': 0, 'scope': 2, 'filter': '(cn=*)', 'typeOnly': False, 'dereferenceAlias': 3, 'base': 'o=test', 'sizeLimit': 0}> sent via DEBUG:ldap3:PROTOCOL:new message id <2> generated DEBUG:ldap3:NETWORK:sending message for DEBUG:ldap3:NETWORK:sent 53 bytes via DEBUG:ldap3:NETWORK:received 158 bytes via DEBUG:ldap3:NETWORK:received 158 bytes via DEBUG:ldap3:NETWORK:received 158 bytes via DEBUG:ldap3:NETWORK:received 158 bytes via DEBUG:ldap3:NETWORK:received 158 bytes via DEBUG:ldap3:NETWORK:received 158 bytes via DEBUG:ldap3:NETWORK:received 146 bytes via DEBUG:ldap3:NETWORK:received 146 bytes via DEBUG:ldap3:NETWORK:received 146 bytes via DEBUG:ldap3:NETWORK:received 146 bytes via DEBUG:ldap3:NETWORK:received 146 bytes via DEBUG:ldap3:NETWORK:received 146 bytes via DEBUG:ldap3:NETWORK:received 146 bytes via DEBUG:ldap3:NETWORK:received 146 bytes via DEBUG:ldap3:NETWORK:received 146 bytes via DEBUG:ldap3:NETWORK:received 146 bytes via DEBUG:ldap3:NETWORK:received 146 bytes via DEBUG:ldap3:NETWORK:received 14 bytes via DEBUG:ldap3:NETWORK:received 18 ldap messages via DEBUG:ldap3:PROTOCOL:SEARCH response entry <{'type': 'searchResEntry', 'dn': 'cn=[62985459]paged_search-6,o=test', 'attributes': {'sn': ['paged_search-6'], 'objectClass': ['inetOrgPerson', 'organizationalPerson', 'Person', 'ndsLoginProperties', 'Top']}, 'raw_attributes': {'sn': [b'paged_search-6'], 'objectClass': [b'inetOrgPerson', b'organizationalPerson', b'Person', b'ndsLoginProperties', b'Top']}}> received via DEBUG:ldap3:PROTOCOL:SEARCH response entry <{'type': 'searchResEntry', 'dn': 'cn=[62985459]paged_search-5,o=test', 'attributes': {'sn': ['paged_search-5'], 'objectClass': ['inetOrgPerson', 'organizationalPerson', 'Person', 'ndsLoginProperties', 'Top']}, 'raw_attributes': {'sn': [b'paged_search-5'], 'objectClass': [b'inetOrgPerson', b'organizationalPerson', b'Person', b'ndsLoginProperties', b'Top']}}> received via DEBUG:ldap3:PROTOCOL:SEARCH response entry <{'type': 'searchResEntry', 'dn': 'cn=[62985459]paged_search-4,o=test', 'attributes': {'sn': ['paged_search-4'], 'objectClass': ['inetOrgPerson', 'organizationalPerson', 'Person', 'ndsLoginProperties', 'Top']}, 'raw_attributes': {'sn': [b'paged_search-4'], 'objectClass': [b'inetOrgPerson', b'organizationalPerson', b'Person', b'ndsLoginProperties', b'Top']}}> received via DEBUG:ldap3:PROTOCOL:SEARCH response entry <{'type': 'searchResEntry', 'dn': 'cn=[62985459]paged_search-3,o=test', 'attributes': {'sn': ['paged_search-3'], 'objectClass': ['inetOrgPerson', 'organizationalPerson', 'Person', 'ndsLoginProperties', 'Top']}, 'raw_attributes': {'sn': [b'paged_search-3'], 'objectClass': [b'inetOrgPerson', b'organizationalPerson', b'Person', b'ndsLoginProperties', b'Top']}}> received via DEBUG:ldap3:PROTOCOL:SEARCH response entry <{'type': 'searchResEntry', 'dn': 'cn=[62985459]paged_search-2,o=test', 'attributes': {'sn': ['paged_search-2'], 'objectClass': ['inetOrgPerson', 'organizationalPerson', 'Person', 'ndsLoginProperties', 'Top']}, 'raw_attributes': {'sn': [b'paged_search-2'], 'objectClass': [b'inetOrgPerson', b'organizationalPerson', b'Person', b'ndsLoginProperties', b'Top']}}> received via DEBUG:ldap3:PROTOCOL:SEARCH response entry <{'type': 'searchResEntry', 'dn': 'cn=[62985459]paged_search-1,o=test', 'attributes': {'sn': ['paged_search-1'], 'objectClass': ['inetOrgPerson', 'organizationalPerson', 'Person', 'ndsLoginProperties', 'Top']}, 'raw_attributes': {'sn': [b'paged_search-1'], 'objectClass': [b'inetOrgPerson', b'organizationalPerson', b'Person', b'ndsLoginProperties', b'Top']}}> received via DEBUG:ldap3:PROTOCOL:SEARCH response entry <{'type': 'searchResEntry', 'dn': 'cn=[81539822]search-9,o=test', 'attributes': {'sn': ['search-9'], 'objectClass': ['inetOrgPerson', 'organizationalPerson', 'Person', 'ndsLoginProperties', 'Top']}, 'raw_attributes': {'sn': [b'search-9'], 'objectClass': [b'inetOrgPerson', b'organizationalPerson', b'Person', b'ndsLoginProperties', b'Top']}}> received via DEBUG:ldap3:PROTOCOL:SEARCH response entry <{'type': 'searchResEntry', 'dn': 'cn=[81539822]search-8,o=test', 'attributes': {'sn': ['search-8'], 'objectClass': ['inetOrgPerson', 'organizationalPerson', 'Person', 'ndsLoginProperties', 'Top']}, 'raw_attributes': {'sn': [b'search-8'], 'objectClass': [b'inetOrgPerson', b'organizationalPerson', b'Person', b'ndsLoginProperties', b'Top']}}> received via DEBUG:ldap3:PROTOCOL:SEARCH response entry <{'type': 'searchResEntry', 'dn': 'cn=[81539822]search-7,o=test', 'attributes': {'sn': ['search-7'], 'objectClass': ['inetOrgPerson', 'organizationalPerson', 'Person', 'ndsLoginProperties', 'Top']}, 'raw_attributes': {'sn': [b'search-7'], 'objectClass': [b'inetOrgPerson', b'organizationalPerson', b'Person', b'ndsLoginProperties', b'Top']}}> received via DEBUG:ldap3:PROTOCOL:SEARCH response entry <{'type': 'searchResEntry', 'dn': 'cn=[81539822]search-6,o=test', 'attributes': {'sn': ['search-6'], 'objectClass': ['inetOrgPerson', 'organizationalPerson', 'Person', 'ndsLoginProperties', 'Top']}, 'raw_attributes': {'sn': [b'search-6'], 'objectClass': [b'inetOrgPerson', b'organizationalPerson', b'Person', b'ndsLoginProperties', b'Top']}}> received via DEBUG:ldap3:PROTOCOL:SEARCH response entry <{'type': 'searchResEntry', 'dn': 'cn=[81539822]search-5,o=test', 'attributes': {'sn': ['search-5'], 'objectClass': ['inetOrgPerson', 'organizationalPerson', 'Person', 'ndsLoginProperties', 'Top']}, 'raw_attributes': {'sn': [b'search-5'], 'objectClass': [b'inetOrgPerson', b'organizationalPerson', b'Person', b'ndsLoginProperties', b'Top']}}> received via DEBUG:ldap3:PROTOCOL:SEARCH response entry <{'type': 'searchResEntry', 'dn': 'cn=[81539822]search-4,o=test', 'attributes': {'sn': ['search-4'], 'objectClass': ['inetOrgPerson', 'organizationalPerson', 'Person', 'ndsLoginProperties', 'Top']}, 'raw_attributes': {'sn': [b'search-4'], 'objectClass': [b'inetOrgPerson', b'organizationalPerson', b'Person', b'ndsLoginProperties', b'Top']}}> received via DEBUG:ldap3:PROTOCOL:SEARCH response entry <{'type': 'searchResEntry', 'dn': 'cn=[81539822]search-3,o=test', 'attributes': {'sn': ['search-3'], 'objectClass': ['inetOrgPerson', 'organizationalPerson', 'Person', 'ndsLoginProperties', 'Top']}, 'raw_attributes': {'sn': [b'search-3'], 'objectClass': [b'inetOrgPerson', b'organizationalPerson', b'Person', b'ndsLoginProperties', b'Top']}}> received via DEBUG:ldap3:PROTOCOL:SEARCH response entry <{'type': 'searchResEntry', 'dn': 'cn=[81539822]search-2,o=test', 'attributes': {'sn': ['search-2'], 'objectClass': ['inetOrgPerson', 'organizationalPerson', 'Person', 'ndsLoginProperties', 'Top']}, 'raw_attributes': {'sn': [b'search-2'], 'objectClass': [b'inetOrgPerson', b'organizationalPerson', b'Person', b'ndsLoginProperties', b'Top']}}> received via DEBUG:ldap3:PROTOCOL:SEARCH response entry <{'type': 'searchResEntry', 'dn': 'cn=[81539822]search-1,o=test', 'attributes': {'sn': ['search-1'], 'objectClass': ['inetOrgPerson', 'organizationalPerson', 'Person', 'ndsLoginProperties', 'Top']}, 'raw_attributes': {'sn': [b'search-1'], 'objectClass': [b'inetOrgPerson', b'organizationalPerson', b'Person', b'ndsLoginProperties', b'Top']}}> received via DEBUG:ldap3:PROTOCOL:SEARCH response entry <{'type': 'searchResEntry', 'dn': 'cn=[50120048]search-2,o=test', 'attributes': {'sn': ['search-2'], 'objectClass': ['inetOrgPerson', 'organizationalPerson', 'Person', 'ndsLoginProperties', 'Top']}, 'raw_attributes': {'sn': [b'search-2'], 'objectClass': [b'inetOrgPerson', b'organizationalPerson', b'Person', b'ndsLoginProperties', b'Top']}}> received via DEBUG:ldap3:PROTOCOL:SEARCH response entry <{'type': 'searchResEntry', 'dn': 'cn=[50120048]search-1,o=test', 'attributes': {'sn': ['search-1'], 'objectClass': ['inetOrgPerson', 'organizationalPerson', 'Person', 'ndsLoginProperties', 'Top']}, 'raw_attributes': {'sn': [b'search-1'], 'objectClass': [b'inetOrgPerson', b'organizationalPerson', b'Person', b'ndsLoginProperties', b'Top']}}> received via DEBUG:ldap3:BASIC:done SEARCH operation, result DEBUG:ldap3:BASIC:start UNBIND operation via DEBUG:ldap3:PROTOCOL:UNBIND request sent via DEBUG:ldap3:PROTOCOL:new message id <3> generated DEBUG:ldap3:NETWORK:sending message for DEBUG:ldap3:NETWORK:sent 7 bytes via DEBUG:ldap3:NETWORK:closing connection for DEBUG:ldap3:NETWORK:connection closed for DEBUG:ldap3:BASIC:stop collecting usage metrics DEBUG:ldap3:BASIC:done UNBIND operation, result Have fun, Giovanni From cannatag at gmail.com Tue May 19 00:15:37 2015 From: cannatag at gmail.com (Giovanni Cannata) Date: Tue, 19 May 2015 00:15:37 +0200 Subject: [python3-ldap] ldap3 0.9.8.4 released Message-ID: Hello, ldap3 0.9.8.4 is out, Changelog: * 0.9.8.4 2015.05.19 - Added EXTENDED log detail level with prettyPrint description of ldap messages - fixed logging of IPv6 address description - fixed checking of open address when dns returns more than one ip for the same host - fixed selection of proper address when failing back from IPv6 to IPv4 and vice-versa - when sending controls controlValue is now optional (as stated in RFC 4511), specify None to not send it I refined the logging messages and added an EXTENDED level of details in logging. At this level each LDAP message (sent or received) is decoded in the log using the prettyPrint function of the excellent pyasn1 package. THe line prefix means outgoing (>>) or incoming (<<) messages For example: DEBUG:ldap3:EXTENDED:ldap message sent via - tls not started - listening - SyncStrategy>: >>LDAPMessage: >> messageID=2 >> protocolOp=ProtocolOp: >> bindRequest=BindRequest: >> version=3 >> name=b'' >> authentication=AuthenticationChoice: >> sasl=SaslCredentials: >> mechanism=b'DIGEST-MD5' >> credentials=b'username="cn=testSASL,o=test",realm="openldap.hyperv",nonce="6o2FZgrC13AywVh7sW6TUatRJxwsothglmQ7TykswbI=",cnonce="a2256f76206ea3b9efc8a6855f508bca",digest-uri="ldap/",qop=auth,nc=00000001,charset="utf-8",response="3681ea074f63ad5c23befec7e5dcd1cf"' DEBUG:ldap3:NETWORK:sent 283 bytes via - tls not started - listening - SyncStrategy> DEBUG:ldap3:NETWORK:received 62 bytes via - tls not started - listening - SyncStrategy> DEBUG:ldap3:NETWORK:received 1 ldap messages via - tls not started - listening - SyncStrategy> DEBUG:ldap3:EXTENDED:ldap message received via - tls not started - listening - SyncStrategy>: < Hello everybody, I'm going to move ldap3 into production/stable. I have still to complete the docs, and hope to finish this task in the next few weeks. There is still something that you think is missing for the 1.0 version? Thanks, Giovanni -------------- next part -------------- An HTML attachment was scrubbed... URL: From lorenzo at sancho.ccd.uniroma2.it Thu Jun 25 11:59:56 2015 From: lorenzo at sancho.ccd.uniroma2.it (Lorenzo M. Catucci) Date: Thu, 25 Jun 2015 11:59:56 +0200 Subject: [python3-ldap] Missing support for atomic test and set operations [Re: Moving ldap3 into production/stable] Message-ID: <558BD11C.90604@sancho.ccd.uniroma2.it> Giovanni, as for your question "There is still something that you think is missing for the 1.0 version?" I don't know if support for the atomic test and set [1] was just overlooked, or deliberately kept out. From reading the available docs, I cannot find out how to replace the following python-ldap script fragment: c = ldap.open('ldap.example.com') DN = 'cn=objectcn,dc=ldap,dc=example,dc=com' ATT = 'cn' OVAL = 'testValue' NVAL = 'setValue' c.modify_s(DN, [(ldap.MOD_ADD, ATT, OVAL), (ldap.MOD_DELETE, ATT, NVAL)]) which would translate to the following LDIF atomic change operation: dn: cn=objectcn,dc=ldap,dc=example,dc=com changetype: modify delete: cn cn: testValue - add: cn cn: setValue - Thank you very much, yours lorenzo [1] e.g. see: http://www.openldap.org/lists/openldap-software/200009/msg00559.html -- +-------------------------+----------------------------------------------+ | Lorenzo M. Catucci | Centro di Calcolo e Documentazione | | catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor Vergata" | | | Via O. Raimondo 18 ** I-00173 ROMA ** ITALY | | Tel. +39 06 7259 2255 | Fax. +39 06 7259 2125 | +-------------------------+----------------------------------------------+ From cannatag at gmail.com Sat Jun 27 11:35:30 2015 From: cannatag at gmail.com (Giovanni Cannata) Date: Sat, 27 Jun 2015 11:35:30 +0200 Subject: [python3-ldap] Test Message-ID: <558e6e67.2864c20a.4b4aa.ffffe674@mx.google.com> Testt -------------- next part -------------- An HTML attachment was scrubbed... URL: From cannatag at gmail.com Wed Aug 26 21:11:45 2015 From: cannatag at gmail.com (Giovanni Cannata) Date: Wed, 26 Aug 2015 21:11:45 +0200 Subject: [python3-ldap] A faster decoder for ldap3 1.0 Message-ID: Hello everybody, I'm about to release version 1,0 of ldap3. I've written a BER decoder (BER is the undrlying network protocol of LDAP) to substitute pyasn1. Obviously the network and ldap server have a major role in the overall spped of the library, but in my test I get . In my tests decoding is more than 10x faster then pyasn1. Is anybody interested in testing it? You can get the source in dev at https://github.com/cannatag/ldap3.git. There is a new boolean argume nt "fast_decoder" in the connection object that is True by default. If you set it to False you get the older pyasn1 decoder. By the way encoding is still done via pyasn1. Let me know if you have problems and if it seem faster for you. Thanks, Giovanni From cito at online.de Wed Aug 26 21:55:54 2015 From: cito at online.de (Christoph Zwerschke) Date: Wed, 26 Aug 2015 21:55:54 +0200 Subject: [python3-ldap] A faster decoder for ldap3 1.0 In-Reply-To: References: Message-ID: <55DE19CA.7070609@online.de> Hi Giovanni, I remember one minor issue with ldap3, namely that some constants have very long names which are difficult to read and write and remember and also not compatible with the old ldap2 (like SEARCH_SCOPE_WHOLE_SUBTREE instead of SCOPE_SUBTREE). Maybe you can add the old shorter names as aliases in version 1.0? -- Christoph From cannatag at gmail.com Wed Aug 26 22:09:59 2015 From: cannatag at gmail.com (Giovanni Cannata) Date: Wed, 26 Aug 2015 22:09:59 +0200 Subject: [python3-ldap] A faster decoder for ldap3 1.0 In-Reply-To: <55DE19CA.7070609@online.de> References: <55DE19CA.7070609@online.de> Message-ID: Hi Christoph, that already changed. Now the constants are much shorter but still meaininful (You can still use the longer format, that resembles the official names in the RFC). Furthermore I've moved the values of constants from integer to string, usually with the same constant name. This is helpful when debugging the code, and improve readability of the source. The docs are also improved, take a look at http:// ldap3.readthedocs.org. I'm writing a tutorial on ldap too, hope to have it completed for the 1.0 release. Bye, Giovanni 2015-08-26 21:55 GMT+02:00 Christoph Zwerschke : > Hi Giovanni, > > I remember one minor issue with ldap3, namely that some constants have very > long names which are difficult to read and write and remember and also not > compatible with the old ldap2 (like SEARCH_SCOPE_WHOLE_SUBTREE instead of > SCOPE_SUBTREE). Maybe you can add the old shorter names as aliases in > version 1.0? > > -- Christoph > _______________________________________________ > python3-ldap mailing list > python3-ldap at python.org > https://mail.python.org/mailman/listinfo/python3-ldap From cito at online.de Wed Aug 26 22:18:09 2015 From: cito at online.de (Christoph Zwerschke) Date: Wed, 26 Aug 2015 22:18:09 +0200 Subject: [python3-ldap] A faster decoder for ldap3 1.0 In-Reply-To: References: <55DE19CA.7070609@online.de> Message-ID: <55DE1F01.20405@online.de> Thanks. Had't followed the project lately, but glad to see all the great progress. The new docs are superb! -- Chris Am 26.08.2015 um 22:09 schrieb Giovanni Cannata: > Hi Christoph, that already changed. Now the constants are much shorter > but still meaininful (You can still use the longer format, that > resembles the official names in the RFC). Furthermore I've moved the > values of constants from integer to string, usually with the same > constant name. This is helpful when debugging the code, and improve > readability of the source. The docs are also improved, take a look at > http:// ldap3.readthedocs.org. I'm writing a tutorial on ldap too, > hope to have it completed for the 1.0 release. > > Bye, > Giovanni