LDAP - Proper objectClass ordering?

Author

Proper objectClass ordering?

Philip Prindeville

2006-08-29, 7:07 pm

Hi.

I'm dealing with an LDAP server that answers queries with data
that has the objectClass attribute in no particular order, i.e. and
had a question for you all.

Is there an easy way to get the values of:

$mesg->entry(0)->get_value('objectClass')

into hierarchical sorted value? I'm seeing returned values like:

iplanet-am-user-service, iplanet-am-managed-person, top, iPlanetPreferences, person, inetuser, inetOrgPerson, inetAdmin, organizationalPerson

which clearly isn't correct. I figure that the Schema class probably
contains enough information in this to put things into the proper order
that the hierarchy implies.

(Of course, multiple inheritance makes things a little tricky...)

Reason is we want to be able to look at an object with a browser, and
go up the (objectClass) tree until we find a node on the tree that (mostly)
knows how to render this object.

For instance, if we don't know how to render a node as an 'inetOrgPerson',
well, we could render it as an 'organizationalPerson' instead, etc.

Does it make sense to add a convenience wrapper that handles this logic
for us (and perhaps caches the schema conveniently to avoid having to
pull it down multiple times)?

Thanks,

-Philip

Mike Jackson

2006-08-29, 7:07 pm

Philip Prindeville wrote:
> Hi.
>
> I'm dealing with an LDAP server that answers queries with data
> that has the objectClass attribute in no particular order, i.e. and
> had a question for you all.

objectClass is a multivalued attribute, and RFC 2251 says that the
return order of multivalued attributes is not guaranteed.

> Is there an easy way to get the values of:
>
> $mesg->entry(0)->get_value('objectClass')
>
> into hierarchical sorted value? I'm seeing returned values like:
>
> iplanet-am-user-service, iplanet-am-managed-person, top,
> iPlanetPreferences, person, inetuser, inetOrgPerson, inetAdmin,
> organizationalPerson
>
>
> which clearly isn't correct.

Yes, it is correct. See above.

> I figure that the Schema class probably
> contains enough information in this to put things into the proper order
> that the hierarchy implies.
>
> (Of course, multiple inheritance makes things a little tricky...)

There is the superclass() method, which will return the immediate parent
object class of a given object class.

> Reason is we want to be able to look at an object with a browser, and
> go up the (objectClass) tree until we find a node on the tree that (mostly)
> knows how to render this object.

Please define "render".

Object composition and class hierarchy has absolutely no relation to DIT
structure and hierarchy.

--
http://www.netauth.com - LDAP Directory Consulting

Philip Prindeville

2006-08-29, 7:07 pm

Mike Jackson wrote:
> Philip Prindeville wrote:
>
> objectClass is a multivalued attribute, and RFC 2251 says that the
> return order of multivalued attributes is not guaranteed.
>
>
>
> Yes, it is correct. See above.

Ok, I'll rephrase. It's not in hierarchical ordering, which is what we
desire.

>
> There is the superclass() method, which will return the immediate
> parent object class of a given object class.

Right, but that's a fair amount of work. I'm wondering if there might be a
more compact representation of the objectclass stacking hierarchy that
could lend itself to a quick, efficient convenience method for reordering
the objectclass array, such as:

my %objectClassIndicies = (
'top' => 0,
'person' => 1,
'organizationalPerson' => 2,
...
);

then you could just do an array sort based on:

sub ocReorder
{
$objectClassIndicies{$a} <=> $objectClassIndicies{$b};
}

or better yet, have the convenience function do it for you.

>
>
> Please define "render".

Well, in this case, it gets printed out in HTML as part of an online
directory
CGI, with certain fields converted into links, etc. For instance, the
person's
email address gets rendered as:

<a href=mailto:@mail@>@displayName@</a>

and becomes clickable. Likewise for their pager number, their phone
number, their network share, etc.

> Object composition and class hierarchy has absolutely no relation to
> DIT structure and hierarchy.
>

Ok... so... I'm not sure what you're saying. Is the Schema info not
the proper
place then to assemble the class hierarchy?

-Philip

Mike Jackson

2006-08-29, 7:07 pm

Philip Prindeville wrote:

> Right, but that's a fair amount of work. I'm wondering if there might be a
> more compact representation of the objectclass stacking hierarchy that
> could lend itself to a quick, efficient convenience method for reordering
> the objectclass array, such as:
>
> my %objectClassIndicies = (
> 'top' => 0,
> 'person' => 1,
> 'organizationalPerson' => 2,
> ...
> );
>
>
> then you could just do an array sort based on:
>
> sub ocReorder
> {
> $objectClassIndicies{$a} <=> $objectClassIndicies{$b};
> }
>
>
> or better yet, have the convenience function do it for you.
>

>
>
> Well, in this case, it gets printed out in HTML as part of an online
> directory
> CGI, with certain fields converted into links, etc. For instance, the
> person's
> email address gets rendered as:
>
> <a href=mailto:@mail@>@displayName@</a>
>
> and becomes clickable. Likewise for their pager number, their phone
> number, their network share, etc.
>

Have a look at a program I created for emailman.com:

http://www.emailman.com/ldap/search/ldapsearch.pl

Try some searches and examine the output. Is this what you are trying to do?

>
>
> Ok... so... I'm not sure what you're saying. Is the Schema info not
> the proper
> place then to assemble the class hierarchy?

Yes, it's the place. I just misunderstood what you were trying to say
initially.

However, I still don't understand your use case. Why do you need to
"know how to render an object"? Why do you need to understand a class
hierarchy, unless you are modifying subclassed objects? What is to know,
and how does it related to classing? Just render objects from the
attributes and values which are recieved. Write subs to wrap certain
named attribute's values with urls, etc...

--
http://www.netauth.com - LDAP Directory Consulting

Philip Prindeville

2006-08-29, 7:07 pm

Mike Jackson wrote:
> Philip Prindeville wrote:
>
>
>
>
>
> Have a look at a program I created for emailman.com:
>
> http://www.emailman.com/ldap/search/ldapsearch.pl
>
> Try some searches and examine the output. Is this what you are trying
> to do?

Somewhat... although we have local attributes and subclasses which I
omitted from my example.

We also have several different LDAP spaces (sigh... that could have been
planned a lot better) where disjoint information about a particular user
is kept, and it needs to be groveled out of each of them (at least until we
achieve some reunification... if that ever happens).

>
>
> Yes, it's the place. I just misunderstood what you were trying to say
> initially.
>
> However, I still don't understand your use case. Why do you need to
> "know how to render an object"? Why do you need to understand a class
> hierarchy, unless you are modifying subclassed objects? What is to
> know, and how does it related to classing? Just render objects from
> the attributes and values which are recieved. Write subs to wrap
> certain named attribute's values with urls, etc...
>

Because users can have multiple inheritance from more than one objectClass,
and some objectClasses I don't understand (so I have to start at the
subclass
and start peeling off layers until I get to a superclass that makes
sense to me).

Not all of the subclasses are worth knowing how to render.

Some of them are just inetOrgPerson's with a couple of additional fields
thrown in... this extra layer of subclassing isn't important to me.

But not everyone is an inetOrgPerson. Some are "contacts", and have to
be rendered differently. They also don't need to be groveled for in
parallel
LDAP spaces, since they only exist locally.

-Philip

Quanah Gibson-Mount

2006-08-29, 7:07 pm

--On Tuesday, August 29, 2006 10:18 AM -0600 Philip Prindeville
<philip.prindeville@albertsons.com> wrote:

> Hi.
>
> I'm dealing with an LDAP server that answers queries with data
> that has the objectClass attribute in no particular order, i.e. and
> had a question for you all.
>
> Is there an easy way to get the values of:
>
> $mesg->entry(0)->get_value('objectClass')
>
> into hierarchical sorted value? I'm seeing returned values like:
>
> iplanet-am-user-service, iplanet-am-managed-person, top,
> iPlanetPreferences, person, inetuser, inetOrgPerson, inetAdmin,
> organizationalPerson
>
>
> which clearly isn't correct. I figure that the Schema class probably
> contains enough information in this to put things into the proper order
> that the hierarchy implies.
>
> (Of course, multiple inheritance makes things a little tricky...)
>
> Reason is we want to be able to look at an object with a browser, and
> go up the (objectClass) tree until we find a node on the tree that
> (mostly)
> knows how to render this object.
>
> For instance, if we don't know how to render a node as an 'inetOrgPerson',
> well, we could render it as an 'organizationalPerson' instead, etc.
>
> Does it make sense to add a convenience wrapper that handles this logic
> for us (and perhaps caches the schema conveniently to avoid having to
> pull it down multiple times)?

Use OpenLDAP 2.3, and use the valsort attribute overlay, which was written
exactly for this purpose. It lets you assign hidden "weights" to
attributes so that the return order is guaranteed when the server is
queried.

--Quanah

--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

Philip Prindeville

2006-08-29, 7:07 pm

Quanah Gibson-Mount wrote:
>
>
> --On Tuesday, August 29, 2006 10:18 AM -0600 Philip Prindeville
> <philip.prindeville@albertsons.com> wrote:
>
>
> Use OpenLDAP 2.3, and use the valsort attribute overlay, which was
> written exactly for this purpose. It lets you assign hidden "weights"
> to attributes so that the return order is guaranteed when the server
> is queried.
>
> --Quanah
>
>
> --
> Quanah Gibson-Mount
> Principal Software Developer
> ITS/Shared Application Services
> Stanford University
> GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

Regrettably, this isn't an option. The servers are controlled by
another group,
and they use COTS.

Whatever I do, it has to be client side.

-Philip

Peter Marschall

2006-09-02, 7:04 pm

On Tuesday, 29. August 2006 19:43, Philip Prindeville wrote:
> Right, but that's a fair amount of work. I'm wondering if there might be a
> more compact representation of the objectclass stacking hierarchy that
> could lend itself to a quick, efficient convenience method for reordering
> the objectclass array, such as:
>
> my %objectClassIndicies = (
> 'top' => 0,
> 'person' => 1,
> 'organizationalPerson' => 2,
> ...
> );

It is not possible for the general case with multiple inheritance and
auxiliary object classes.
You cannot sort them linearly in a unique way.

Besides that an object does not need to store all objectclasses up to 'top'.
It is perfectly legal for an inetOrgPerson to only have
objectclass: inetOrgPerson
So you need to walk through the schema anyway to be on the safe side.

Hope it helps
Peter

--
Peter Marschall
peter@adpm.de

Sponsored Links