...

Proposal

Query Engine

Split the MethodInvokationAuthorizer MethodInvocationAuthorizer in two different interfaces:

1. RegionInvocationAuthorizer: internal with a default implementation provided out of the box. It should just check whether the user can execute queries on the region (DATA:READ:regionName).
2. MethodInvokationAuthorizerMethodInvocationAuthorizer: public, the default implementation out of the box will be RestrictedMethodInvocationAuthorizer. This interface is intended to be implemented by users whenever they want a more fine grained control about which methods should be whitelisted, it can extend the default implementation or totally override it. The interface will have only one method and it should throw NotAuthorizedException (non-checked exception) whenever it detects that the user should not be allowed to execute that particular method during the OQL execution. The whole information about the method to invoke and the target class can be obtained from the Method class itself, so the signature won't have the region as part of the parameters.

...

The DefaultQueryService will use an empty implementation of both interfaces if security is disabled or the flag QueryService.allowUntrustedMethodInvocation is set as true (as it works right now). If security is enabled the default RegionInvocationAuthorizer will be used, and the MethodInvokationAuthorizer MethodInvocationAuthorizer will be set as the default (blacklists everything) or, if present, the custom implementation will be used. In runtime, the RegionInvocationAuthorizer will be always invoked first; if it succeeds and the user has privileges to query the region, the configured implementation of MethodInvokationAuthorizer MethodInvocationAuthorizer will be executed.

Once the split is done, Geode could provide several implementations out of the box to match common use cases (like whitelisting methods specified by custom patterns), and even integrate some or all of those implementations with gfsh commands to manage the behavior in runtime.

...

The <query-service> element must be defined at the cache level and it will contain any configuration related to OQL, including the custom MethodInvokationAuthorizer MethodInvocationAuthorizer. This will also allow further additions and configuration options in the future, or even replace the current system properties used to configure the QueryService with new child elements and/or attributes in the <query-service>. The element would look like the following (the properties are just examples):

...