[python-ldap] Attribute syntax definitions

[Nyasha Chigwamba]

On Mon, Dec 3, 2012 at 11:12 PM, Michael Ströder <michael at stroeder.com>wrote:

> Nyasha Chigwamba wrote:
> >     What you do you want to do with LDAP syntaxes?
> >
> > I would like to I would like to validate input in my client when adding
> or
> > modifying new object instances.
>
> LDAP syntaxes are most times not sufficient for input validation of
> attribute
> values. Most times one needs more. In web2ldap I have plugin classes I can
> register for LDAP syntaxes and attribute types. They have full access to
> the
> whole LDAP entry and the subschema. Very handy.
>
> > I would like to be able to create new instances of the various object
> classes
> > from my client with the correct attributes in the correct format.
>
> How generic should this be?
>
At the moment, I am only creating instances of a single object class that
is defined on the server. Eg. In my AD server, I can create an instance of
the user class. The inheritance hierarchy of the user class contains
(person, organizationalPerson, top). I do not support multiple inheritance
but it might become a requirement. Multiple inheritance being, for example,
creating a instance of the user class that also inherits from the account
class.

>
> Note that DIT content rules also influence the set of attributes usable in
> an
> entry. Some developers of a widely used LDAP client blame MS AD for not
> having
> LDAPv3 compliant subschema but they fail to evaluate the DIT content
> rules...
>
I also discovered that I got a larger set of  attributes when I included
the ditContentRules in my result attributes. However, I noticed that
ditStructureRules are not return by Active Directory (optional as per
relevant RFC)

>
> Luckily python-ldap supports DIT content rules out-of-the-box.
>
> > The ideal
> > would be to support the all CRUD functions but I can live with create,
> read,
> > and delete. In my client, I am doing the following:
> > 1. Read the dn of the 'subschemaSubentry'  from the root DSE (bearing in
> mind
> > that this might not be possible due to access restrictions).
>
> 'subschemaSubentry' is an operational attribute in every entry. Bear in
> mind
> that each part of the DIT could have its own subschema.
>
Do you mean in contexts where, for example, referrals are used?

>
> > 2. Read the schema by searching the dn retrieved in (1) for
> 'objectClasses'
> > and 'attributeTypes'.
> > 3. Package the schema into a format that is compatible with the rest of
> my
> > application (pretty much the object classes and their attributes,
> including
> > data_formats of the attributes). [I should probably only restrict this
> to the
> > leaf nodes in the object class hierarchies]
>
> You should also implement subschema caching.
>
> > 4. The next task that I would like to tackle involves listing all the
> > instances of each [structural?] object class under a given base dn.
> > 5. If (4) works, I would like to start adding and deleting the instances.
>
> How generic is this meant to be? Do you aim to fully support all LDAP
> servers?
> Are you using python-ldap's module ldap.schema for that?
>
It would be great if I can support all LDAP servers.

>
> Ciao, Michael.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20121212/db541b16/attachment.html>