directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Zoerner (JIRA)" <directory-...@incubator.apache.org>
Subject [jira] Commented: (DIREVE-276) Search for super OC does not return subclasses if add op does not add complete objectClass lineage
Date Tue, 18 Oct 2005 18:32:45 GMT
    [ http://issues.apache.org/jira/browse/DIREVE-276?page=comments#action_12332389 ] 

Stefan Zoerner commented on DIREVE-276:
---------------------------------------

There are different options for a server to act, if a user adds an entry, where objectClasses
are missing, like this one (comparable to your example)

dn: cn=Kate Bush,dc=apache,dc=org
objectClass: top
objectClass: person
sn: Bush
cn: Kate Bush

I am not sure whether it is defined by the standard, how to react, but here are the options
I found with example implementations (if I found any).

(1) Just add it as is. That is, the corresponding entry looks exactly like above (plus operational
attributes)
Example for a server which acts like this: 
OpenLDAP 2.1

(2) Fill the missing objectClasses during the add, resulting in an entry which looks like
this:

dn: cn=Kate Bush,dc=apache,dc=org
objectClass: top
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
sn: Bush
cn: Kate Bush

Examples for a server which behaves like that: 
Sun Java System Directory Server 5.2
IBM Tivoli Directory Server 6.0
Active Directory Application Mode (ADAM) (but it adds other classes as above)
Novell eDirectory 8.7.3

(3) Refuse to add the entry, e.g. with an error code for Schema Violation.
Examples for a server which behaves like that: 
(none found yet)

I recommend application developers not to add such an entry, and then they do not face these
different server reactions.

For our situation, I would recommend to implement  (2) -- just as you suggested. (3) is better
than (1) from my point of view, because people like to search by base classes, and it can't
be up to us to check the whole hierarchy within a search operation (to expensive). 

> Search for super OC does not return subclasses if add op does not add complete objectClass
lineage
> --------------------------------------------------------------------------------------------------
>
>          Key: DIREVE-276
>          URL: http://issues.apache.org/jira/browse/DIREVE-276
>      Project: Directory Server
>         Type: Bug
>     Reporter: Alex Karasulu
>     Assignee: Alex Karasulu
>      Fix For: 0.9.4

>
> If I add an entry with objectClass inetOrgPerson to the directory but do not include
in the objectClass attribute values for the super objectClasses like organizationalPerson
and person then (objectClass=person) will not return the entry when it is in scope.  To fix
this is simple.  Instead of adding tests for lineage on search operations which would be a
nightmare we should pay the price on the add operation.  Basically an interceptor can check
that the lineage of objectClasses is present within the objectClass attribute.  If not then
it can be injected into the entry before the add operation takes place.
> I don't know if this is correct behavior but it cannot hurt.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message