Menu
▾
▴
python-ldap-dev
|
From: David L. <dav...@ds...> - 2000-12-10 13:29:03
|
On Thu, 16 Nov 2000, Jeffrey C. Ollie typed thusly:
> I've gotten today's CVS version to compile against OpenLDAP 2.0.7. It
> seems that the OpenLDAP people dropped a number of macros between v1
> and v2. A fairly simple patch that #ifdefs the dropped macros and
> everything compiles fine.
I think it will be more beneficial to just remove those dead constants from
the python namespace altogether.
Does anyone ever use them? Here's the list
MAX_ATTR_LEN
REQ_UNBIND_30
REQ_DELETE_30
REQ_ABANDON_30
AUTH_SIMPLE_30
AUTH_KRBV41_30
AUTH_KRBV42_30
FILTER_PRESENT_30
SUBSTRING_INITIAL_30
SUBSTRING_ANY_30
SUBSTRING_FINAL_30
URL_ERR_NOTLDAP
URL_ERR_NODN
CACHE_BUCKETS
CACHE_OPT_CACHENOERRS
CACHE_OPT_CACHEALLERRS
DEFAULT_REFHOPLIMIT
OPT_DNS
OPT_REFERRALS
Does anyone even use the cache control stuff?
If you do, I will suggest that the future cache calls be of the form
l.set_cache_options("noerrs", "blah")
Instead of
l.set_cache_options(_ldap.CACHE_OPT_CACHENOERRS | _ldap.BLAH)
It reads a bit easier too. comments?
What about the referrals and DNS options? someone must, surely :)
i think also that a string-base approach would be better there too.
>>> l.options
("restart",)
>>> l.options = l.options + "referrals",
>>> l.options
("referrals", "restart")
>>> l.options = l.options + "snork", # silently ignored??
("referrals", "restart")
i've been talking to michael stroeder about getting all these things
together in a clean way for a '2.0' release of python-ldap. this means
that strong changes like the above are quite possible.
d
--
David Leonard Dav...@ds...
DSTC Room:78-632 Ph:+61 7 336 58358
The University of Queensland http://www.dstc.edu.au/
QLD 4072 AUSTRALIA B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8
I put my chin on my knee, and looked for flaws in the soft grain of my
beige plastic monitor casing. - Julian Assange
Index: constants.c
===================================================================
RCS file: /cvsroot/python-ldap/python-ldap/Modules/constants.c,v
retrieving revision 1.5
diff -u -r1.5 constants.c
--- constants.c 2000/08/13 15:00:59 1.5
+++ constants.c 2000/12/10 13:07:58
@@ -66,7 +66,7 @@
add_int(d,VERSION1);
add_int(d,VERSION2);
add_int(d,VERSION);
- add_int(d,MAX_ATTR_LEN);
+ /* add_int(d,MAX_ATTR_LEN); */
add_int(d,TAG_MESSAGE);
add_int(d,TAG_MSGID);
@@ -79,9 +79,9 @@
add_int(d,REQ_MODRDN);
add_int(d,REQ_COMPARE);
add_int(d,REQ_ABANDON);
- add_int(d,REQ_UNBIND_30);
- add_int(d,REQ_DELETE_30);
- add_int(d,REQ_ABANDON_30);
+ /* add_int(d,REQ_UNBIND_30); */
+ /* add_int(d,REQ_DELETE_30); */
+ /* add_int(d,REQ_ABANDON_30); */
/* reversibles */
@@ -106,9 +106,9 @@
add_int(d,AUTH_KRBV4);
add_int(d,AUTH_KRBV41);
add_int(d,AUTH_KRBV42);
- add_int(d,AUTH_SIMPLE_30);
- add_int(d,AUTH_KRBV41_30);
- add_int(d,AUTH_KRBV42_30);
+ /* add_int(d,AUTH_SIMPLE_30); */
+ /* add_int(d,AUTH_KRBV41_30); */
+ /* add_int(d,AUTH_KRBV42_30); */
add_int(d,FILTER_AND);
add_int(d,FILTER_OR);
add_int(d,FILTER_NOT);
@@ -118,13 +118,13 @@
add_int(d,FILTER_LE);
add_int(d,FILTER_PRESENT);
add_int(d,FILTER_APPROX);
- add_int(d,FILTER_PRESENT_30);
+ /* add_int(d,FILTER_PRESENT_30); */
add_int(d,SUBSTRING_INITIAL);
add_int(d,SUBSTRING_ANY);
add_int(d,SUBSTRING_FINAL);
- add_int(d,SUBSTRING_INITIAL_30);
- add_int(d,SUBSTRING_ANY_30);
- add_int(d,SUBSTRING_FINAL_30);
+ /* add_int(d,SUBSTRING_INITIAL_30); */
+ /* add_int(d,SUBSTRING_ANY_30); */
+ /* add_int(d,SUBSTRING_FINAL_30); */
add_int(d,SCOPE_BASE);
add_int(d,SCOPE_ONELEVEL);
add_int(d,SCOPE_SUBTREE);
@@ -135,34 +135,24 @@
/* (errors.c contains the error constants) */
- add_int(d,DEFAULT_REFHOPLIMIT);
-#ifdef LDAP_CACHE_BUCKETS
- add_int(d,CACHE_BUCKETS);
-#endif
-#ifdef LDAP_CACHE_OPT_CACHENOERRS
- add_int(d,CACHE_OPT_CACHENOERRS);
-#endif
-#ifdef LDAP_CACHE_OPT_CACHEALLERRS
- add_int(d,CACHE_OPT_CACHEALLERRS);
-#endif
+ /* add_int(d,DEFAULT_REFHOPLIMIT); */
+ /* add_int(d,CACHE_BUCKETS); */
+ /* add_int(d,CACHE_OPT_CACHENOERRS); */
+ /* add_int(d,CACHE_OPT_CACHEALLERRS); */
add_int(d,FILT_MAXSIZ);
add_int(d,DEREF_NEVER);
add_int(d,DEREF_SEARCHING);
add_int(d,DEREF_FINDING);
add_int(d,DEREF_ALWAYS);
add_int(d,NO_LIMIT);
-#ifdef LDAP_OPT_DNS
- add_int(d,OPT_DNS);
-#endif
-#ifdef LDAP_OPT_REFERRALS
- add_int(d,OPT_REFERRALS);
-#endif
+ /* add_int(d,OPT_DNS); */
+ /* add_int(d,OPT_REFERRALS); */
add_int(d,OPT_RESTART);
/* XXX - these belong in errors.c */
- add_int(d,URL_ERR_NOTLDAP);
- add_int(d,URL_ERR_NODN);
+ /* add_int(d,URL_ERR_NOTLDAP); */
+ /* add_int(d,URL_ERR_NODN); */
add_int(d,URL_ERR_BADSCOPE);
add_int(d,URL_ERR_MEM);
|
|
From: Michael <mi...@st...> - 2000-12-10 13:51:51
|
David Leonard wrote: > > Does anyone ever use them? Here's the list > [..] > OPT_REFERRALS I was using it. > Does anyone even use the cache control stuff? Yes. I think we should leave the 1.x stuff as is and start with python-ldap-ext based on OpenLDAP 2.0.x... Ciao, Michael. |
|
From: David L. <dav...@ds...> - 2000-12-10 22:27:56
|
On Sun, 10 Dec 2000, Michael Ströder typed thusly: > I think we should leave the 1.x stuff as is and start with > python-ldap-ext based on OpenLDAP 2.0.x... Okay, to keep everyone on the list informed: Michael, as a knowledgable Karlsruhe local, showed me all the local restaurants that have closed down and then we discussed the direction for python-ldap. After a few drinks, and a discussion on cats, we agreed on the following plan: * python-ldap-1.10 will be tidied up, with just the memory-leak patches applied, and a proper documentation build. (ie no v3 changes will be applied as it breaks v2 builds.) A final release will be made. * A new python-ldap-2.0 will be started, with an API that is likely to be somewhat incompatible with that of p-l-1.10. In particular, the following will be the major compatibility targets: + Python-2.0 support (ie unicode) + OpenLDAP-2.0 support (ie LDAPv3/LDAP-EXT) This means that people relying on v2 client/servers should be happy enough with a reasonably stable release. And people wanting to live in the 3rd millenium should be happy with a version (relatively) free of legacy support. Please, comment! Are there problems with the above plan? In addition, I seek more comment on any more changes that the _ldap library may need to support LDAPv3 connections. (Remember that the purpose of this module is not to give an abstraction of X.500 directory services, but rather to provide an abstraction of the LDAP C API.) d -- David Leonard Dav...@ds... DSTC Room:78-632 Ph:+61 7 336 58358 The University of Queensland http://www.dstc.edu.au/ QLD 4072 AUSTRALIA B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8 I put my chin on my knee, and looked for flaws in the soft grain of my beige plastic monitor casing. - Julian Assange |
|
From: Michael <mi...@st...> - 2000-12-11 13:32:53
|
David Leonard wrote: > > On Sun, 10 Dec 2000, Michael Ströder typed thusly: > > I think we should leave the 1.x stuff as is and start with > > python-ldap-ext based on OpenLDAP 2.0.x... > > Okay, to keep everyone on the list informed: > > Michael, as a knowledgable Karlsruhe local, showed me all the local > restaurants that have closed down and then we discussed the direction for > python-ldap. After a few drinks, and a discussion on cats, we agreed on > the following plan: Been there, got a t-shirt(?). > In addition, I seek more comment on any more changes that the _ldap library > may need to support LDAPv3 connections. (Remember that the purpose of this > module is not to give an abstraction of X.500 directory services, but rather > to provide an abstraction of the LDAP C API.) I would like to stay as close as possible to the new LDAP-EXT API in OpenLDAP 2.0.x since this API already trys to give some level of abstraction (SASL for providing several authentication methods etc.). Once again the things I would like to see: - LDAPv3 binding - proper support for search continuations (LDAPv3 referrals) - SSL and STARTTLS support - Access to schema functions (would save lots of work in Python applications) - Virtual List Controls (rather low-prio) IMHO python-ldap 2.0 should provide as much access to the C-API as possible (except the functions marked as deprecated in ldap.h. We can put a Python-written abstraction layer above this later. > Please, comment! Yes! I hope this discussion is not "local". ;-) Ciao, Michael. |
|
From: Federico Di G. <fo...@mi...> - 2000-12-12 16:56:50
|
Scavenging the mail folder uncovered Michael Ströder's letter:
> > In addition, I seek more comment on any more changes that the _ldap library
> > may need to support LDAPv3 connections. (Remember that the purpose of this
> > module is not to give an abstraction of X.500 directory services, but rather
> > to provide an abstraction of the LDAP C API.)
>
> I would like to stay as close as possible to the new LDAP-EXT API in
> OpenLDAP 2.0.x since this API already trys to give some level of
> abstraction (SASL for providing several authentication methods
> etc.).
i agree.
> Once again the things I would like to see:
>
> - LDAPv3 binding
> - proper support for search continuations (LDAPv3 referrals)
> - SSL and STARTTLS support
> - Access to schema functions (would save lots of work in Python
> applications)
mmm... what are schema functions? some time ago i was trying to
code some v3 schema support in pure python (do you remember) but
i never tidied up the code to something really useable. (nobody
ever tried my code to... *grin*)
ciao,
federico
--
Federico Di Gregorio
MIXAD LIVE Chief of Research & Technology fo...@mi...
Debian GNU/Linux Developer & Italian Press Contact fo...@de...
The number of the beast: vi vi vi. -- Delexa Jones
|
|
From: Michael <mi...@st...> - 2000-12-12 17:18:25
|
Federico Di Gregorio wrote: > > mmm... what are schema functions? some time ago i was trying to > code some v3 schema support in pure python (do you remember) but > i never tidied up the code to something really useable. (nobody > ever tried my code to... *grin*) The schema functions are exposed in ldap_schema.h of OpenLDAP 2.0.x and are exactly what you started to write (off course I remember). Ciao, Michael. |
|
From: Federico Di G. <fo...@mi...> - 2000-12-13 09:23:31
|
Scavenging the mail folder uncovered Michael Ströder's letter:
> Federico Di Gregorio wrote:
> >
> > mmm... what are schema functions? some time ago i was trying to
> > code some v3 schema support in pure python (do you remember) but
> > i never tidied up the code to something really useable. (nobody
> > ever tried my code to... *grin*)
>
> The schema functions are exposed in ldap_schema.h of OpenLDAP 2.0.x
> and are exactly what you started to write (off course I remember).
so, maybe, we dont need a pure python implementation. mmm... maybe
that'll make my job easier and i'll produce something useable in
shorter time... (cvs updating now...)
ciao,
federico
--
Federico Di Gregorio
MIXAD LIVE Chief of Research & Technology fo...@mi...
Debian GNU/Linux Developer & Italian Press Contact fo...@de...
God is real. Unless declared integer. -- Anonymous female programmer
|
|
From: David M. <da...@es...> - 2000-12-19 01:42:26
|
Hello, I haven't been following the list too closely, so forgive me if some of this has already been discussed. I think unicode support is a great thing to add. I have already played with language tags a bit, but still being on python 1.5.2 for the most part, haven't had a convenient way to do the unicode conversions. What would be cool is if python-ldap could not only accept unicode strings, but also automatically apply the language tag when creating or modifying attributes (i.e. cn;lang-de). Of course, I can also imagine situations where you wouldn't want the module making assumptions like this. Also, I haven't seen any discussion of SSL support. I for one would like the module to be able to do an SSL handshake to port 636 (or whatever it is) to protect the credentials when simple auth is being used. I have to admit I haven't looked into whether open LDAP supports this, or whether it is something that would have to be cobbled in. If open LDAP doesn't have this, and doesn't provide for socket callbacks, then it could be tricky. It would also be cool to get the Kerberos V5 GSS-API SASL mechanism going. I'm interested in doing the work to add these features. Dave On Sun, 10 Dec 2000, David Leonard wrote: > On Sun, 10 Dec 2000, Michael Str=F6der typed thusly: > > I think we should leave the 1.x stuff as is and start with > > python-ldap-ext based on OpenLDAP 2.0.x... >=20 > Okay, to keep everyone on the list informed: >=20 > Michael, as a knowledgable Karlsruhe local, showed me all the local > restaurants that have closed down and then we discussed the direction for > python-ldap. After a few drinks, and a discussion on cats, we agreed on > the following plan: >=20 > =09* python-ldap-1.10 will be tidied up, with just the memory-leak > =09 patches applied, and a proper documentation build. (ie no v3 > =09 changes will be applied as it breaks v2 builds.) A final release > =09 will be made. >=20 > =09* A new python-ldap-2.0 will be started, with an API that is likely > =09 to be somewhat incompatible with that of p-l-1.10. In particular, > =09 the following will be the major compatibility targets: > =09=09+ Python-2.0 support (ie unicode) > =09=09+ OpenLDAP-2.0 support (ie LDAPv3/LDAP-EXT) >=20 > This means that people relying on v2 client/servers should be happy enoug= h > with a reasonably stable release. And people wanting to live in the 3rd > millenium should be happy with a version (relatively) free of legacy supp= ort. >=20 > Please, comment! Are there problems with the above plan? >=20 > In addition, I seek more comment on any more changes that the _ldap libra= ry > may need to support LDAPv3 connections. (Remember that the purpose of thi= s > module is not to give an abstraction of X.500 directory services, but rat= her > to provide an abstraction of the LDAP C API.) >=20 > d > --=20 > David Leonard Dav...@ds... > DSTC Room:78-632 Ph:+61 7 336 58358 > The University of Queensland http://www.dstc.edu.au/ > QLD 4072 AUSTRALIA B73CD65FBEF4C089B79A8EBADF1A932F1= 3EA0FC8 >=20 > I put my chin on my knee, and looked for flaws in the soft grain of my > beige plastic monitor casing. - Julian Assange >=20 > _______________________________________________ > Python-LDAP-dev mailing list > Pyt...@li... > http://lists.sourceforge.net/mailman/listinfo/python-ldap-dev >=20 |
|
From: David L. <dav...@cs...> - 2000-12-19 02:06:43
|
On Mon, 18 Dec 2000, David Margrave typed thusly: > Also, I haven't seen any discussion of SSL support. yes this is an important thing. i'm hoping that it will be more or less transparent to the api user. perhaps it will be done by just by providing set/get/check-certiciate hooks to the user like the python socket module does for those who really care :) > It would also be cool to get the Kerberos V5 GSS-API SASL mechanism going. I'm not overly familiar with this, i'm afraid -- David Leonard Dav...@ds... CRC For Distributed Systems Technology Room:78-632 Ph:+61 7 336 58358 The University of Queensland http://www.dstc.edu.au/ QLD 4072 AUSTRALIA B73CD65FBEF4C089B79A8EBADF1A932F13EA0FC8 Cassette tapes have an almost unlimited capacity for data. - Commodore 64 Programmer's Reference Guide (1983) |
|
From: Michael <mi...@st...> - 2000-12-19 08:45:32
|
David Margrave wrote: > > What would be cool is if python-ldap could not only accept unicode > strings, but also automatically apply the language tag when > creating or modifying attributes (i.e. cn;lang-de). I don't think that the C module should do high-level operations like this. I can imagine that it's worth to write a Python class for it - contributions and detailed suggestions welcome. But let's stick to things found in OpenLDAP 2.0's ldap.h first. > Also, I haven't seen any discussion of SSL support. I for one would > like > the module to be able to do an SSL handshake to port 636 (or whatever it > is) to protect the credentials when simple auth is being used. OpenLDAP 2 has support for LDAP via SSL (URL scheme ldaps:// -> port 636) and LDAP with STARTTLS. > It would also be cool to get the Kerberos V5 GSS-API SASL mechanism > going. OpenLDAP supports SASL (not only Kerberos) if build with the Cyrus SASL lib. > I'm interested in doing the work to add these features. Great! Please take a closer look at OpenLDAP 2.0.x. Ciao, Michael. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X