python-ldap-dev

Re: web2ldap with patched python-ldap

[Michael <mi...@st...>]

Konstantin,

sorry for answering so late.

Konstantin Chuguev wrote:
> 
> I could not resist to try the patch I proposed on my web2ldap.

You patched python-ldap?

> Unsurprisingly, it does not work, raising the DECODING_ERROR exception:
> [..]
> I think this can happen when ldap_result() method returns Py_None, as
> your code always assume there is a tuple returned.

Yes.

Can you please send patches to the python-ldap-dev list? Even if
they don't work they are a start of coding the error handling in the
asynchronous calls.

I think David should have a look at it.

Ciao, Michael.

patch: l_ldap_result() now properly raising exceptions

[Michael <mi...@st...>]

Konstantin Chuguev wrote:
> 
> Oughh. After some late hacking tonight, here we are :-)

GREAT!!! It works.

I have attached Konstantin's patch to this message. Could someone
with more Python/C knowledge look into the patched LDAPObject.c
function l_ldap_result() to make sure that we do not introduce new
memory leaks with this patch?

Note: Since the result() method now properly raises exceptions
caused by LDAP errors one might have to add additional exception
handling to the calling Python code.

Ciao, Michael.

Re: patch: l_ldap_result() now properly raising exceptions

[David L. <dav...@cs...>]

On Tue, 17 Oct 2000, Michael Ströder typed thusly:

> Konstantin Chuguev wrote:
> > 
> > Oughh. After some late hacking tonight, here we are :-)
> 
> GREAT!!! It works.
> 
> I have attached Konstantin's patch to this message. Could someone
> with more Python/C knowledge look into the patched LDAPObject.c
> function l_ldap_result() to make sure that we do not introduce new
> memory leaks with this patch?
> 
> Note: Since the result() method now properly raises exceptions
> caused by LDAP errors one might have to add additional exception
> handling to the calling Python code.

fix committed

d
-- 
David Leonard                           Dav...@cs...
Dept of Comp. Sci. and Elec. Engg   _   Room:78-640  Ph:+61 7 336 51187
The University of Queensland       |+|  http://www.csee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8

Curses! - Mojo Jojo

Re: patch: l_ldap_result() now properly raising exceptions

[Michael <mi...@st...>]

David Leonard wrote:
> 
> fix committed

Now I have problems doing an CVS update:

michael@junker:~/src/python-ldap/python-ldap > cvs update .
str...@cv...'s password: 
cvs server: Updating .
cvs server: failed to create lock directory in repository
`/cvsroot/python-ldap/python-ldap': Permission denied
cvs server: failed to obtain dir lock in repository
`/cvsroot/python-ldap/python-ldap'
cvs [server aborted]: read lock failed - giving up

Hmm, this used to work...

Ciao, Michael.

Re: web2ldap with patched python-ldap

[Michael <mi...@st...>]

Konstantin Chuguev wrote:
> 
> > > The only problem is, if the search done in w2lsearch.py returns 
> > > both
> > > normal entries and referral(s), an exception will be raised in 
> > > the end,
> > > passing the control to w2lreferral.py, and the list of normal 
> > > values will
> > > be lost. Perhaps you should handle except ldap.PARTIAL_RESULTS in
> > > w2lsearch.py itself?
> >
> > Hmm, I think if doing a search with scope one/sub and a search
> > continuation is received together with normal search results
> > l_ldap_result() should return a different result type instead of
> > raising ldap.PARTIAL_RESULTS. I could then gracefully handle the
> > search continuation in the while loop. Do you think this could be
> > done based on the OpenLDAP 1.2.x libs?
> >
> 
> For a one-level search (browsing mode), it would be nice if entries referenced
> by referrals and thus held on other servers were shown almost like local
> entries in the list

I tried this with the new patch.

Unfortunately if a referral (search continuation) during one level
search raises an exception there will no results returned
afterwards. The next call of result() method (ldap_result() function
of C API) blocks. Also the exception object does neither contain the
full LDAP URL or the DN of the referral entry.

=> there's currently no way to retrieve search continuations and
normal search results together without modifying python-ldap.

Ciao, Michael.