Hi, Only following the Oak development with half attention, this popped in my attention. As an Oak use I have to care for index-configuration. And am not happy with the current situation. So I take the opportunity of this mail to hook in.
Angela Schreiber: IMO this is a very troublesome setup which may lead to serious security issues. Jukka Zitting: I'm not too worried about this, since the index definitions themselves seldom contain any confidential information, and if they do, it's always possible to read-protect them. The actual indexed content is always hidden. You are right in the security aspect of disclosure of information, the set-up may not be problematic. The issue relevant here, is the organizational one. For example, if you only want to index content within /foo/bar, you could add the relevant index definitions in /foo/bar/oak:index. A nice side-effect of this approach is that someone with write permission within /foo/bar would then also be able to define new indexes for that subtree. Though writing data for storage and a configuration is all writing, one means saving data and one is changing the system-configuration. It's a valid requirement that you want to separate the permissions to the one from the other. Which in the current suggested approach is difficult to achieve. Using the Hierarchy for separating the concerns is simple and efficient. That is why I would opt for the /system path approach. I have the impression that this thread is partly covering a second topic: the implications of the distributed configuration I'd leave it up to the administrator of a particular deployment to decide if and how index definitions need to be protected. It overlaps a bit with the Root-Node. In the thread it is about the set-up for the AccessControl for this Node. But it shares the more general topic, that having the configuration with the content: It imposes every Users of the hierarchy to have the case-handling. Take the simplest application for a repository, a packaging: It must be decided should the configuration be included in the package or not? I am definitely biased by my most dominant use of a Repository as a Storage for a CMS. But for this case I have some doubts in the benefits of a distributed search configuration. The independent features pos requirements to the search configuration mostly about the properties and to a very small extend to paths. This shapes my evaluation that the gain in security by moving the configuration to its own branch is higher than the possible gain of keeping it on root and treat it specially there. Christian
