I suggest to use proper nodetypes for index definitions and I second Angela's opinion, that for "internal" structures, we should be more rigid. I quickly browsed through the code, and I could not find any mixin type that would allow adding a oak:index node. so how would you define an index on an arbitrary subtree?
suggest: * create a "oak:Indexable" mixin nodetype, * and make the oak:QueryIndexDefinition not extending from nt:unstructured, but define it properly. regards, toby btw: nodetypes should be uppercase (like class and interface names. (yes, JCR had this wrong)). On Wed, Nov 13, 2013 at 9:29 AM, Angela Schreiber <[email protected]> wrote: > one more question regarding the node type of the index definition > (oak:queryIndexDefinition): > > assume that someone makes the an index definition versionable. > is it the intended behaviour that the index content stored underneath > the index definition is being treated with OPV VERSION as it's > mandated by nt:unstructured? > > the 'reindex' property in contrast is marked with OPV IGNORE while > 'async' and 'type' don't have the OPV flag set which afaik means > that they get OPV COPY. > > kind regards > angela > > > On 11/13/13 11:21 AM, "Angela Schreiber" <[email protected]> wrote: > >>hi >> >>while looking at OAK-1173 and OAK-1172 i once again looked at >>the indexing code. >> >>currently the index definitions are located directly underneath >>the root node and don't have any specific permission setup >>associated with them. >> >>what does that mean: everyone that has read/write access on the >>root node will be able to read/write the index definitions as >>in the default setup the permissions are inherited through the >>node hierarchy. >> >>IMO this is a very troublesome setup which may lead to serious >>security issues. >> >>therefore i would like us to discuss >> >>- if the location of the index definitions is well chosen. >> have those that originally setup that structure thought about >> securit concerns? what was the result? >> for example: why are the index definitions not located underneath >> jcr:system? this was IMO more appropriate. >> >>- the node type of the oak:index parent node: >> it's currently nt:unstructured which will allow anyone with read >> access to create whatever additional content there. this doesn't >> make sense IMO. >> and: is the index related code prepared to deal with any kind of >> garbage content in the oak:index tree? >> >>- the node type definition of the oak:queryIndexDefinition: >> it currently extends from nt:unstructured which also allows to >> place any kind of child nodes. is this really intended? and is >> the index code prepared to deal with *any* kind of content in >> the subtree of the definition? >> and shouldn't the index definition be considered 'protected' from >> a JCR point of view? >> >>- the access rights defined on the index definition irrespective of >> their location: >> - who needs access to the index definitions? >> - must they be readable to everyone? >> - should read access be restricted? >> - who should/must be able to add/change/remove the index definitions? >> >>IMO we need to address this very soon before someone starts >>to use OAK in a productive environment. >> >>i will open a separate JIRA issue such that we can include this >>into the overall planning. >> >>kind regards >>angela >> >
