Emmanuel Lecharny wrote:
Hi guys,I have been working for the last 3 days on DIRSERVER-758, and while trying to fix it, I just felt like I have found something pretty ugly. I need your opinion on some points, and choices.Just to summarize, DIRSERVER-758 was about creating an entry with attributes not existing or not part of any objectclasses.For instance, here is one kind of entry which is problematic : dn: c=france, ou=system objectclass : inetOrgPerson sn: emmanuel This entry has four problems : 1) The 'c' attribute is not declared in the entry's attributes2) The 'c' attribute is associated with the 'country' object class, which is not listed as an attribute for this entry 3) Some object classes are missing : 'top', 'person', 'organizationalPerson' and of course 'country'4) Som attributs are missing : 'sn', 'cn', declared in objectclass 'person'Ok, so far, it seems that this entry is not correct.
Yes this is bad you should reject any entry that is being added like this. It's a schema violation.
Alas, we can inject
it in the server :(
This is what I was trying to fix. Now, here are my questions : 1) Regarding missing ObjectClasses 1-a)We can add some of the missing ObjectClasses, like 'top', 'person', 'organizationalPerson', because we have all the needed informations to rebuild the hierarchy starting from 'inetOrgPerson'.Q : Is it a good idea to do so, instead of simply rejecting the entry ?
Yeah this is an acceptable situation since inetOrgPerson implies person anyway.
Did not my doco discuss this? I already fixed this issue by replacing the missing ancestors but not top.
Please do not add 'top' because you will bloat the objectClass index. Top is injected on the return of all entries if not already present.
Top is always assumed.
2) Regarding missing attributes 2-a)If we have a RDN with an attribute not declared as an attribute of the entry, its should be rejected, as stated by RFC 2251 ( 4.7. Add Operation :"...
Yes it should be rejected.
- attributes: the list of attributes that make up the content of the
entry being added. Clients MUST include distinguished values
(those forming the entry's own RDN) in this list,..."
Q : Is that ok with you to reject such entries ?
Yes absolutely we should not allow the use of attributes that do not exist in the entry in the name of the entry.
2-b) If an attribute is added to the entry, but without the associated ObjectClass, then it should not be accepted, unless we have added the missing ObjectClass following 1-a aboveQ : wdyt ?
Well in the 1-a case I think we're covered since inetOrgPerson is going to allow everything that person does plus additional things.
But in short I'd answer yes.
3) Reagrding use of JNDI APIIn some place of the code ( mainly tests ),
Yeah we shouold fix these in those tests. If non tests use it this is a serious problem. I don't think anything but tests use this.
we use the
Context.createSubcontext( name ) method. This lead to a serious problem, because we have no clue about which objectclass to use and no clue about
Do not presume any objectClass to use here. This is just flawed. However I think JNDI states that for LDAP providers this is to create a javaContainer from the java schema. I'd have to look into this.
Yeah I'd stay away from this stuff. ...
Other cases are pretty obvious :- an entry with missing attributes (declared as MUST in the entry's ObjectClass) should be considered as an error - an RDN like test=acme should not be accepted, unless 'test' is declared as a valid attribute.
You're giving too much thought to this one. Don't worry about it. We just need to strip this stuff out of tests and where java tests are concerned with java schema usage we have to figure out what JNDI expects to do. I think without an Attributes object in createSubcontext( name ) this javaContainer is the objectClass used. The server side JNDI provider should substitute for this automatically.
Special cases are like collective attributes, extensibleObject objectclasses, operational attributes, top, are supposed to be handled correctly.
Yep I agree. Alex
begin:vcard fn:Alex Karasulu n:Karasulu;Alex org:Apache Software Foundation;Apache Directory adr:;;1005 N. Marsh Wind Way;Ponte Vedra ;FL;32082;USA email;internet:[EMAIL PROTECTED] title:Member, V.P. tel;work:(904) 791-2766 tel;fax:(904) 808-4789 tel;home:(904) 808-4789 tel;cell:(904) 315-4901 note;quoted-printable:AIM: alexokarasulu=0D=0A= MSN: [EMAIL PROTECTED] Yahoo!: alexkarasulu=0D=0A= IRC: aok=0D=0A= PGP ID: 1024D/4E1370F8 BBCC E8D8 8756 2D51 C3D4 014A 3662 F96F 4E13 70F8=0D=0A= x-mozilla-html:FALSE url:http://people.apache.org/~akarasulu version:2.1 end:vcard
