Menu
▾
▴
python-ldap-dev
|
From: Tjabo K. <t.k...@bi...> - 2002-05-17 09:46:42
|
hi, is it possible to fetch a list of all supported objectClasses and their attribs from an openLDAP server using python-ldap? how? thanks in advance, Tjabo Kloppenburg - billiton internet services GmbH Entwicklung+Technik -------------------------------------------------------------- direct phone: 0271/30386-19 direct mail: t.k...@bi... Weitere Informationen finden Sie unter http://www.billiton.de/ |
|
From: Igor S. <st...@sc...> - 2002-05-17 10:15:46
|
Heya,
On Fre, 2002-05-17 at 11:45, Tjabo Kloppenburg wrote:
> is it possible to fetch a list of all supported objectClasses and their a=
ttribs
> from an openLDAP server using python-ldap?
>=20
> how?
actually it is, but the representation type of attributeTypes and
objectClasses is 'string', so you get a list of strings that you first
have to parse somehow if you want to utilize it... see [1], it works for
me, but I'm pretty sure I left some schema attributes (like STRUCTURAL
etc.) out, so I might just as well fail to return correct values for
your own objectClass... it parses 'person' pretty neat though...
HTH,
Igor
[1]:
#!/usr/bin/python2.1
import ldap
import string
import re
# bind credentials
ADMIN_DN =3D "<admin dn>"
ADMIN_PW =3D "<admin bind pw>"
# which objectClass(es) should we look for
O_CLASSES =3D ['person']
# some global RE objects
search_oid =3D re.compile("^\\( (?P<oid>\d.*\d) .*")
search_name =3D re.compile(".* NAME '(?P<name>[a-zA-Z0-9_]+)' .*")
search_desc =3D re.compile(".* DESC '(?P<desc>.*)' .*")
search_must_attr =3D
re.compile(".*\s?MUST\s?\\(\s?(?P<must_attr>[a-zA-Z0-9_$\
]+)\s?\\)\s?.*")
search_may_attr =3D
re.compile(".*\s?MAY\s?\\(\s?(?P<may_attr>[a-zA-Z0-9_$ ]+)\s?\\)\s?.*")
def init_all():
filter =3D ".*NAME '%s'.*" % O_CLASSES[0]
del O_CLASSES[0]
for cl in O_CLASSES:
filter +=3D "|.*NAME '%s'.*" % O_CLASSES[0]
ls =3D re.compile(filter, re.I)
con =3D ldap.open("212.75.33.146")
con.simple_bind_s(ADMIN_DN,ADMIN_PW)
entries =3D con.search_s("cn=3DSubschema", ldap.SCOPE_BASE, \
"objectclass=3Dsubschema", ['objectclasses'])
ocs =3D entries[0][1]['objectClasses']
return [oc for oc in ocs if ls.search(oc)]
def parseIt():
ocs =3D init_all()
ret =3D {}
for i in ocs:
key =3D search_name.sub("\g<name>", i)
ret[key] =3D {}
ret[key]['OID'] =3D search_oid.sub("\g<oid>", i)
if search_desc.search(i):
ret[key]['DESC'] =3D search_desc.sub("\g<desc>", i)
else:
ret[key]['DESC'] =3D ""
if search_must_attr.search(i):
ret[key]['MUST'] =3D [attr.strip() for attr in \
string.split(search_must_attr.sub("\g<must_attr>", i), "$")]
else:
ret[key]['MUST'] =3D []
if search_may_attr.search(i):
ret[key]['MAY'] =3D [attr.strip() for attr in \=20
string.split(search_may_attr.sub("\g<may_attr>", i), "$")]
else:
ret[key]['MAY'] =3D []
return ret
def getAllAttributes():
attrs =3D []
ocs =3D parseIt()
for key in ocs.keys():
attrs =3D attrs + ocs[key]['MUST'] + ocs[key]['MAY']
return attrs
--=20
ScanPlus GmbH NOC Ulm - Germany - Griesbadgasse 7-13 - D 89073 Ulm
TEL +49 731 920 13 100 - FAX +49 731 920 13 290
eMail: su...@sc...
Amtsgericht Ulm - HRB3220 - Geschaeftsfuehrer: Juergen Hoermann
|
|
From: <mi...@st...> - 2002-05-17 21:39:35
|
Igor Stroh wrote: > > actually it is, but the representation type of attributeTypes and > objectClasses is 'string', so you get a list of strings that you first > have to parse somehow if you want to utilize it... see [1], it works for > me, but I'm pretty sure I left some schema attributes (like STRUCTURAL > etc.) out, so I might just as well fail to return correct values for > your own objectClass... it parses 'person' pretty neat though... I've recently checked in the patches contributed by Hans Aschauer which wraps the schema parser function in OpenLDAP 2 libs and provide a new sub module ldap.schema. I also made some changes to the Python parts which I will check in this weekend. Well, full LDAPv3 schema support goes far beyond just knowing which attribute types are required/allowed. Especially it would be very interesting to implement a set of syntaxes with their matching rules. This would allow to check the syntax of data input and display the data with more a-priori knowledge. Ciao, Michael. |
|
From: Tjabo K. <t.k...@bi...> - 2002-05-21 07:06:49
|
hi, > I've recently checked in the patches contributed by Hans Aschauer > which wraps the schema parser function in OpenLDAP 2 libs and > provide a new sub module ldap.schema... so this is part of python-ldap? tk. -- Mit freundlichem Gruß Tjabo Kloppenburg - billiton internet services GmbH Entwicklung+Technik -------------------------------------------------------------- direct phone: 0271/30386-19 direct mail: t.k...@bi... Weitere Informationen finden Sie unter http://www.billiton.de/ |
|
From: <mi...@st...> - 2002-05-28 11:11:54
|
Tjabo Kloppenburg wrote: > >>I've recently checked in the patches contributed by Hans Aschauer >>which wraps the schema parser function in OpenLDAP 2 libs and >>provide a new sub module ldap.schema... > > so this is part of python-ldap? It *will be* part of python-ldap. It's not ready to be released yet. BTW: Just fetching objectClass definition is the easy part of the show. We have to think about how to implement and register known LDAP syntaxes for displaying, matching and input handling. Ciao, Michael. |
|
From: <mi...@st...> - 2002-05-30 11:46:26
|
je...@ne... wrote: > On Mon, May 27, 2002 at 08:36:11PM +0200, Michael Str=F6der wrote: >=20 >>BTW: Just fetching objectClass definition is the easy part of the=20 >>show. We have to think about how to implement and register known=20 >>LDAP syntaxes for displaying, matching and input handling. >=20 > What do you mean by 'matching'? Matching different values in reversed > polish notation according to their syntaxes and matching rules? Is that= > not supposed to be done by the LDAP server? Yes it's done by the LDAP server when processing search and=20 compare requests. But it's also handy for having it at the=20 client-side. E.g. in recent web2ldap I'm checking for=20 characteristic attributes (attributes used for forming RDN) and=20 disallow modifying it in the normal modify input form since weird=20 things can happen on various LDAP servers. Now I can only do case-insensitive string matching which is most=20 times right. But in a completely correct implementation the=20 matching should be done according to the matching rules defined=20 for these attributes used. > And what about 'input > handling' -- client-side classchecking? Syntax checking of attribute values in user's input. > I guess I'm totally wrong, but I > have no idea how schema parsing might be usefull except displaying > available classes and attributetypes... Think of displaying attribute values in a UI. It helps if you have=20 knowledge about the syntax used: normal UTF-8 strings vs. ASCII=20 strings, E-mail addresses as mailto:-link or URLs as active links=20 or... Ciao, Michael. |
|
From: Hans A. <Han...@Ph...> - 2002-05-31 09:15:30
|
On Mittwoch, 29. Mai 2002 13:40, Michael Ströder wrote: [...] > Now I can only do case-insensitive string matching which is most > times right. But in a completely correct implementation the > matching should be done according to the matching rules defined > for these attributes used. Michael, what do you think, would it be worth the effort digging into the openldap sources in order to pythonize the server-side syntax checking and attribute matching facilities for client use? [One hour later after scanning the openldap sources] I think I could do it, but for this I would need to teach myself "something" about BER. Does anybody know of some high-level overview (i.e. tutorial style, not RFC's) on this basic-encoding-rules thing (and, if possible, how it is used in (open)ldap)? The disadvantage of this borrow-code-from-openldap-approach is that we will face some licensing fun, and that we will get more entangled with the openldap server (i.e. syntax checking is only available for syntaxes supported by the openldap server, etc.) Hans -- Han...@Ph... |
|
From: <mi...@st...> - 2002-06-02 21:18:56
|
Hans Aschauer wrote: > > Michael, what do you think, would it be worth the effort > digging into > the openldap sources in order to pythonize the server-side > syntax checking and attribute matching facilities for client > use? Only if the API is not subject to continous changes. We have to ask that on OpenLDAP-software mailing list. I suspect the answer of Kurt is "don't rely on that API". > [One hour later after scanning the openldap sources] I think I > could do it, but for this I would need to teach myself > "something" about BER. Hmm, if someone is digging into ber.h we're very near to an approach where we re-implement parts of the LDAP protocol engine. > Does anybody know of some high-level overview (i.e. tutorial > style, not RFC's) on this basic-encoding-rules thing (and, if > possible, how it is used in (open)ldap)? There's something called "A Layman's Introduction to BER, DER and ASN.1" on RSA's web site. > The disadvantage of this borrow-code-from-openldap-approach is > that we will face some licensing fun, and that we will get more > entangled with > the openldap server (i.e. syntax checking is only available for > syntaxes supported by the openldap server, etc.) Hmm, then it does not make sense to me. Also I believe that we can come up with a better Pythonic design if we define thoroughly thought Python classes. Ciao, Michael. |
|
From: Hans A. <Han...@Ph...> - 2002-06-03 11:08:19
|
On Sonntag, 2. Juni 2002 20:31, Michael Ströder wrote: > Hans Aschauer wrote: [...] > > Does anybody know of some high-level overview (i.e. tutorial > > style, not RFC's) on this basic-encoding-rules thing (and, if > > possible, how it is used in (open)ldap)? > > There's something called "A Layman's Introduction to BER, DER and > ASN.1" on RSA's web site. Thank you! > Hmm, then it does not make sense to me. Also I believe that we can > come up with a better Pythonic design if we define thoroughly > thought Python classes. Ok, I think you are right. I just took a deeper look at the sources, and the code seems to look like hand-coded regular expressions. Rewriting this in python does really make sense... BTW: Do you know of a more or less complete list of syntax descriptions? I know sites like http://www.alvestrand.no/objectid/top.html, and for many syntaxes there are BNF definitions (which is just fine), but sometimes they reference material which I cannont find online (e.g. the syntax for telefon numbers, 1.3.6.1.4.1.1466.115.121.1.50, is described in E.123). Hans -- Han...@Ph... |
|
From: <mi...@st...> - 2002-06-03 11:51:14
|
Hans Aschauer wrote: > I just took a deeper look at the sources, and > the code seems to look like hand-coded regular expressions. Uurgs! I'd like to see a base class for a LDAP syntax with a method validate() which is called when setting the attribute value. More or less like I'm doing form parameter validation in PyWebLib. Also one could emulate comparison of values by implementing __cmp__(). With such a vehicle it would be easy to implement new syntaxes by just implementing these two methods. > BTW: Do you know of a more or less complete list of syntax descriptions? > [..] > many syntaxes there are BNF definitions (which is just fine), but > sometimes they reference material which I cannont find online (e.g. the > syntax for telefon numbers, 1.3.6.1.4.1.1466.115.121.1.50, is described > in E.123). You hit one of the famous problems in schema handling. The good news is that it seems you understood the problem... ;-) > I know sites like http://www.alvestrand.no/objectid/top.html That's the best I'd come up with. Ciao, Michael. |
|
From: Hans A. <Han...@Ph...> - 2002-06-03 11:55:15
|
On Montag, 3. Juni 2002 13:23, Michael Ströder wrote: > I'd like to see a base class for a LDAP syntax with a method > validate() which is called when setting the attribute value. More > or less like I'm doing form parameter validation in PyWebLib. Also > one could emulate comparison of values by implementing __cmp__(). > With such a vehicle it would be easy to implement new syntaxes by > just implementing these two methods. So this would mean that we change the implementation from "syntaxes are instances of the syntax class" to "syntaxes are subclasses an (abstract) syntax base class". Which objects would then instanciate the syntax classes? Maybe some kind of attribute class instances, through multiple inheritance? This is btw. not the only place where we have to decide if we want to use inheritance or instanciation for schema information. The same thing holds for objectClasses, etc! For objectClasses, inheritance seems to make sense, since they inherit from each other, and I think it would be possible (in python), to build a class hirachy from server information "on the fly". However, this is quite contrary to what I am used to (and I think many other programmers, too): Usually, I consider the class hirachy as part of the API, which is static. > You hit one of the famous problems in schema handling. The good > news is that it seems you understood the problem... ;-) Too bad. Seems to be a lot of work, then! -- Han...@Ph... |
|
From: <mi...@st...> - 2002-08-08 10:25:08
|
Hans Aschauer wrote: > >>I'd like to see a base class for a LDAP syntax with a method >>validate() which is called when setting the attribute value. > > So this would mean that we change the implementation from "syntaxes are > instances of the syntax class" to "syntaxes are subclasses an > (abstract) syntax base class". Which objects would then instanciate the > syntax classes? Maybe some kind of attribute class instances, through > multiple inheritance? This question really drives me nuts. After playing yesterday with kind of a hard-coded class-based syntax handling added to web2ldap I didn't came to a conclusion whether an attribute should simply be an instance of LDAPSyntax class or not. Well, think of matching rules. That really makes it complicated. Frankly, I don't think it's worth the effort. I looked into sub schema sub entries of various public LDAP servers (Netscape 4.x, iPlanet 5.0, Siemens Dir/X, OpenLDAP 1.x/2.x, Innosoft, etc.) and the declaration of syntaxes is so different that it really does not make much sense to read and use the syntax and attribute type declarations from most of the LDAP servers. It's a whole mess out there in the real world! > For objectClasses, inheritance seems to > make sense, since they inherit from each other, and I think it would be > possible (in python), to build a class hirachy from server information > "on the fly". There's not much you have to do with object classes. From my tests I noticed that e.g. declaration of inetOrgPerson differs on servers by various vendors (e.g. Dir/X declares inetOrgPerson as AUXILIARY class derived from top which violates RFC2798). SubSchema.all_attrs() solves all these issues by resolving all MAY and MUST classes for a given list of object classes. Note that you can limit retrieval of sub schema sub entry to object classes by parameter attrs which usually saves a lot of band-width. Ciao, Michael. |
Thanks for helping keep SourceForge clean.
X