Re: winldap?

[Jonathan B. <bo...@us...>]

Good points.

Wldap32.dll does do ssl and sasl easily. TLS I am still trying to figure ou=
t.

I am open to pointers on how to make SASL work for python-ldap on
Windows. I know it is possible with mingw, theoretically. Do I really
need to compile OpenLDAP using cygwin, with a mingw target?

I have been functioning fine without MSYS. I guess it is time to give in.

BTW, does python-ldap use OpenLDAP for schema parsing, or does it
implement this in pure python? I thought I understood correctly that
ldap.schema is all python.

Regards,
Jonathan Bowman

On 12/13/06, Rich Megginson <ric...@gm...> wrote:

> Does wldap32.dll provide SSL/TLS?  Are additional DLLs required for
> that?  Are they present on every Windows install?  What about
> SASL/GSSAPI?  These are, IMHO, essential parts of any reasonable LDAP
> client.  In this day and age, every LDAP client must be able to use
> startTLS, Digest-MD5, and Kerberos auth.
> > Ideally, I think a pure-python implementation of python-ldap is
> > desirable (with less bloat than Twisted+ldaptor, perhaps).
> That would entail a pure python LDAP layer, LDIF parsing layer, BER
> codec layer, as well as a pure SSL layer and a pure SASL/GSSAPI layer.
> For one, doing all of this in pure python would have a seriously
> negative impact on the performance.  For two, this would be duplicating
> all of the work already done to make this all work very well in C (e.g.
> doing SSL is Hard - doing SASL/GSSAPI is Hard - doing BER and LDAP is
> somewhat easier, but why reinvent the wheel?).
> > Until then,
> > would the thing I am describing be something helpful?
> >
> Yes.  It makes sense to leverage as much of the OS resources as
> possible.  One of the problems with this approach is that wldap32 does
> not provide all of the functionality that python-ldap expects to be
> present in the underlying ldap library layer (e.g. schema parsing,
> probabliy more).  So this approach would result in a somewhat "crippled"
> (but perhaps very useful nonetheless) python-ldap.  As well as the
> aforementioned SSL and SASL concerns.
> > Anyway, these are some thoughts for further discussion. At this point,
> > I am open to applying energy in any direction that makes python-ldap
> > more Windows-friendly, as long as I have the know-how (and the time!).
> >
> > Regards,
> > Jonathan Bowman
> >
> >
> >
> > On 12/12/06, Michael Str=F6der <mi...@st...> wrote:
> >
> >> Jonathan Bowman wrote:
> >>
> >>> I am interested in feedback from you regarding the possibility of the
> >>> python-ldap project providing modules that interface with Wldap32.dll
> >>> on Windows. I am currently working on some modules that do this based
> >>> on the python ctypes module.
> >>>
> >>> I have not tried compiling python-ldap on Windows myself, but I do
> >>> note that the currently available win32 binary builds do not support
> >>> SASL. Would providing an interface that uses Wldap32.dll ease the
> >>> pressure on the rest of you to make python-ldap work with OpenLDAP
> >>> compiled on Windows?
> >>>
> >> Jonathan, it would be helpful to also know what your personal needs ar=
e.
> >>
> >> There are several interesting aspects raised here by your proposal:
> >>
> >> 1. Provide Win32 build of python-ldap.
> >>
> >> 2. Support SASL on Win32. (But which mechanisms?)
> >>
> >> 3. Provide continuous support for python-ldap on Win32.
> >>
> >> 4. Using ctypes for implementing the C wrapper.
> >>
> >> For 1. to 3. IMHO this all can be achieved with today's python-ldap
> >> based on OpenLDAP libs. But off course there has to be someone who is
> >> familiar with building Python extension modules for Win32 preferrably
> >> with the MingW tool chain.
> >>
> >> Regarding 2.:
> >> I asked Howard Chu, OpenLDAP core developer whether it's possible to
> >> build Cyrus-SASL on Win32 based on the MingW tool chain. He said they'=
re
> >> doing it all the time with Symas' product. Additionally one would have
> >> to clarify the situation for Kerberos libs (preferrably heimdal).
> >>
> >> Regarding 4.:
> >> I would appreciate to ease the process of adding new functions to the =
C
> >> wrapper part. Personally I have no experiences with ctypes.
> >>
> >> A short look at the history:
> >>
> >> In former times python-ldap, in particular the C wrapper module _ldap,
> >> already contained many ifdef statements for making it build against ol=
d
> >> Umich, Netscape and Novell LDAP libs. This was possible because most o=
f
> >> these APIs mainly sticked to RFC 1823 with only few subtle differences=
.
> >>
> >> RFC 1823 was sufficient at that time. But time went on and the
> >> deficiencies of the API defined in RFC 1823 lead to Internet-draft
> >> draft-ietf-ldapext-ldap-c-api which unfortunately never made it to RFC
> >> status. Also this draft has its deficiencies but nevertheless is the
> >> defacto standard in OpenLDAP today.
> >>
> >> Quite some while ago David and me decided to throw out support for oth=
er
> >> LDAP C APIs than OpenLDAP for several reasons:
> >>
> >> 1. The OpenLDAP libs were actively developed in opposite to the other
> >> LDAP libs and implemented the extended API functions defined in
> >> draft-ietf-ldapext-ldap-c-api with some handy new arguments, like
> >> extended controls, limits and timeout values. E.g. look at declaration
> >> of ldap_search_ext() here:
> >>
> >> http://www.openldap.org/devel/cvsweb.cgi/~checkout~/doc/drafts/draft-i=
etf-ldapext-ldap-c-api-xx.txt
> >>
> >> 2. We wanted to strip down the C part because I am not a C programmer
> >> and David did not have the time to maintain python-ldap anymore.
> >> Therefore I had to make maintenance of the C part as low effort as
> >> possible. Today the C part is half of the size.
> >>
> >> 3. The LDAP C APIs diverged dramatically regarding support for SSL and
> >> SASL. This could no longer be handled by a few ifdef's.
> >>
> >> 4. The API for the Python application cannot be made completey
> >> independent of the underlying C API regarding different feature sets
> >> (also SSL and SASL) because some SASL mechs need call-back.
> >>
> >> 5. New functions appear in the OpenLDAP API every now and then (e.g. s=
ee
> >> Cancel extended operation in the upcoming python-ldap 2.3) but not in
> >> other LDAP C APIs.
> >>
> >> So how to proceed?
> >>
> >> First I don't want to hold anyone back from porting python-ldap to oth=
er
> >> LDAP C libs. But for requirements 1. to 3. instead of taking the
> >> wldap32.dll approach I'd prefer to try together to improve the situati=
on
> >> with building OpenLDAP, Cyrus-SASL, heimdal etc. based on the MingW to=
o
> >> chain.
> >>
> >> Shifting to ctypes is a very interesting option. Even if the C wrapper
> >> API changes we could provide a stable API to the Python applications b=
y
> >> modifying behaviour of ldapobject.LDAPObject (and derived classes).
> >>
> >> 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=3Djoin.php&p=3Dsourceforge&CID=
=3DDEVDEV
> > _______________________________________________
> > Python-LDAP-dev mailing list
> > Pyt...@li...
> > https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
> >
> >
> >
>