|
From: Michael <mi...@st...> - 2001-07-11 09:29:50
|
Konstantin Chuguev wrote: > > Yes, OpenLDAP-2.0.11 and especially recent changes in python-ldap CVS > repository require a new version of patches. I've attached them. I tried these patches. They seem to work (LDAPv3 connects with recent web2ldap 0.9.x :-). But still there's the problem that LDAP URLs in referrals are not properly formatted. From some discussions on openldap-software I suspect the OpenLDAP 2 libs. Example: When searching ldap://ldap.surfnet.nl/c=BE?ou,mail,uid,telephoneNumber,labeledurl,cn,objectClass,displayName?one the OpenLDAP 2 lib returns the referral URL ldap://tor.dante.org.uk:1389?ou,mail,uid,telephoneNumber,labeledurl,cn,objectClass,displayName?one This LDAP URL does not contain a slash behind the hostport part. My LDAP URL parser (usually in nitpicking mode) expects a trailing slash after hostport (which might be empty) if there are any parameters after hostport. Glancing at RFC2255 seems to confirm this assumption: ldapurl = scheme "://" [hostport] ["/" [dn ["?" [attributes] ["?" [scope] ["?" [filter] ["?" extensions]]]]]] I tried to raise this at the OpenLDAP 2 libs but it was rather ignored since I could not provide a detailed example. I could only provide a python-ldap example there but surely Kurt would have pointed me back to bugs in python-ldap. Anybody willing to write a short C source example confirming this possible bug? Search something which returns a referral LDAP URL and look at the LDAP URL returned (switch off automatic referral chasing). > The patches don't change the behaviour of python-ldap when compiled > against OpenLDAPv1, but create an alternative code when used with > OpenLDAPv2. That's great! > Here are the differences between python-ldap compiled > [..] > * new type of data added to the Python dictionary returned as a > result of ldap_result: > Dictionary keys are DNs, values are entry objects. If the key is > empty, the value is the list of referrals (URL text strings). I completely forgot what we've defined in November but web2ldap seems to display the search continuations nicely. ;-) E.g. ldap://ldap.nameflow.net:1389/c%3DFI??base?%28objectclass%3D%2A%29 shows Referral => ldap://193.166.0.77:389/dmdName=FunetDir,%20c=FI??base in search result table. Sorry Konstantin, the on-line demo at http://sites.inka.de:8002/web2ldap is still running with python-ldap built against OpenLDAP 1.2.x. You have to install web2ldap locally to do the testing. Make sure to look at the output of the ConnInfo button to confirm that it says "LDAPv3 connection to:". Ciao, Michael. |
|
From: Michael <mi...@st...> - 2001-07-11 11:26:19
|
Michael Str=F6der wrote:
> =
> Konstantin Chuguev wrote:
> >
> > Yes, OpenLDAP-2.0.11 and especially recent changes in python-ldap CVS=
> > repository require a new version of patches. I've attached them.
> =
> I tried these patches. They seem to work
I noticed another subtle change in the OpenLDAP 2 behaviour: When
adding an attribute to an entry which is unknown to the server
(schema violation) there's just the base expection class
ldap.LDAPError returned containing message ("Undefined attribute
type..."). This makes it impossible to specifically catch e.g.
ldap.OBJECT_CLASS_VIOLATION.
(web2ldap makes extensive use of catching
ldap.OBJECT_CLASS_VIOLATION, ldap.NAMING_VIOLATION and friends to
enable the user to re-edit the input etc.)
I experienced similar behaviour with exceptions raised in case of
referrals received. The ldap.LDAPError base class was raised with
OpenLDAP 2.0.x lib instead of e.g. ldap.PARTIAL_RESULTS raised in
case of OpenLDAP 1.2.x lib. I thought that in this special case it
has to do with the migration from LDAPv2+ pseudo referrals to real
LDAPv3 knowledge references. Not sure about this issue though.
(web2ldap 0.9.x already contains code to handle both cases but I'd
like to get rid of that bloat in the future.)
It seems that the whole exception-based error catching needs to be
tested thoroughly because there are probably other subtle changes in
the OpenLDAP 2 libs as well.
Ciao, Michael.
|
|
From: Michael <mi...@st...> - 2001-07-12 00:06:24
|
Michael Str=F6der wrote: > = > The ldap.LDAPError base class was raised with > OpenLDAP 2.0.x lib instead of e.g. ldap.PARTIAL_RESULTS raised in > case of OpenLDAP 1.2.x lib. Discovered exception class ldap.REFERRAL introduced with LDAPv3 by looking at ldap.h of OpenLDAP 2 and errors.c... Ciao, Michael. |
|
From: Michael <mi...@st...> - 2001-07-11 16:22:33
|
Michael Str=F6der wrote: > = > Konstantin Chuguev wrote: > > > > Yes, OpenLDAP-2.0.11 and especially recent changes in python-ldap CVS= > > repository require a new version of patches. I've attached them. > = > I tried these patches. BTW: I see a lot of hex dump output (ber_dump) to stdin when using these patches to python-ldap. Can I influence the debugging level anywhere? Ciao, Michael. |
|
From: Michael <mi...@st...> - 2001-07-11 09:56:48
|
Steffen, thanks a lot for your patches. Steffen Ries wrote: > = > Michael Str=F6der <mi...@st...> writes: > = > > Anyone did notice the forwarded warning message by Stig about > > possible memory leaks with OpenLDAP 2.0.x API? > > Please glance over it: > > http://www.geocrawler.com/archives/3/1568/2001/6/0/6036658/ > = > I looked through it. > [..] > The attached patch should fix both issues. I tried to merge your patches with the patches provided by Konstantin but it seg faults with OpenLDAP 2.0.11 libs. Since your diff is not against recent CVS version there might be a problem with some small differences. E.g. there's a call "free(dn);" before "return NULL;" in recent CVS version of message.c which affects your first diff. Since I have no idea about the C sources I'd appreciate if you could take a look at the recent CVS version in which some memory leaks were fixed since python-ldap-1.10alpha3. Ciao, Michael. |