1. So that we don't duplicate the same login in multiple places. 2. So that we don't create too many dependencies between modules (not every module should have to deal with programming rights, or rights in general) 3. So that security bugs aren't introduced when someone forgets to check the rights, or if the rights checking mechanism changes (as it is likely to happen soon for programming rights). This is a direct conclusion of the first item, though... 4. A contract when it comes to code is just saying somewhere in a javadoc that "this method must check rights". This is a soft contract, it relies on the attention and patience of the implementor (he should first read the javadoc, then he should actually implement the extra items of this contract). An interface is a hard contract between the implementation and the manager, and only one part needs to implement the contract, the manager. On 08/05/2013 12:39 PM, Eduard Moraru wrote:
I don`t understand. Why not make it the contract of the QueryExecutor that, if it manages possibly sensitive data, it is in charge of checking rights?
This is how we do it for Solr.
Thanks, Eduard
On Mon, Aug 5, 2013 at 1:45 PM, Sergiu Dumitriu <[email protected]> wrote:
We can add another marker interface, PrivilegedQueryExecutor or something like that, which informs that it can execute privileged queries, so it's up to the query manager to prevent them from running in an unprivileged environment.
On 08/05/2013 03:16 AM, Thomas Mortagne wrote:
It's not as simple as moving the ifs from SecureQueryExecutorManager to each QueryExecutor since the query executors don't know if they need to check rights.
On Sun, Aug 4, 2013 at 7:34 PM, Eduard Moraru <[email protected]> wrote:
Hi devs,
It seems that our SecureQueryManager [1] is preventing the execution of queries other than XWQL and HQL in the absence of PR.
However, this is not at all a friendly policy when it comes to extensions. An example of where this is causing problems is Solr queries, where only users (well, document authors) with PR can execute them.
As the subject says, I suggest removing this restriction and leaving rights check to be performed in each QueryExecutor's execute() method.
The associated Jira issue is XWIKI-9386 [2]
Here's my +1.
Thanks, Eduard
-- Sergiu Dumitriu http://purl.org/net/sergiu