geode-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (Jira)" <j...@apache.org>
Subject [jira] [Commented] (GEODE-7283) OQL Method Authorizer in Query Execution Context
Date Fri, 25 Oct 2019 21:20:01 GMT

    [ https://issues.apache.org/jira/browse/GEODE-7283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16960098#comment-16960098
] 

ASF subversion and git services commented on GEODE-7283:
--------------------------------------------------------

Commit bd03dc7ff99e9cf95b3d9a9369ec8b0de308620d in geode's branch refs/heads/feature/GEODE-7258
from Juan José Ramos
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=bd03dc7 ]

GEODE-7283: Store MethodAuthorizer in Context (#4179)

The MethodInvocationAuthorizer should be unique per query and should
not be changed for a particular query while it's being executed so,
starting with this commit, it is directly stored as part of the
ExecutionContext. This also prevents the creation of multiple instances
of the DefaultQueryService and the configured authorizer itself while
the intermediate result objects are being traversed during the query
evaluation.

- Added tests.
- Fixed minor warnings and spelling.
- Replaced usages of 'junit.Assert' by 'assertj'.
- The AttributeDescriptor and MethodDispatch classes do not require
  MethodInvocationAuthorizer as a constructor parameter anymore, the
  authorizer is obtained from the context, and **only** when needed.
- The MethodDispatch class does not internally store and cache the
  MethodInvocationAuthorizer instance anymore, thus allowing Geode to
  change the authorizer in runtime without needing to re-load every
  already known method (expensive due to reflection).
- The ExecutionContext uses a no-op authorizer when created from a
  client cache: authorization and authentication logic happens only on
  server side, and the authorizer will be obtained from the cluster
  configuration service directly instead of the query service when OQL
  security is fully implemented.

> OQL Method Authorizer in Query Execution Context
> ------------------------------------------------
>
>                 Key: GEODE-7283
>                 URL: https://issues.apache.org/jira/browse/GEODE-7283
>             Project: Geode
>          Issue Type: Improvement
>          Components: querying
>            Reporter: Juan Ramos
>            Assignee: Juan Ramos
>            Priority: Major
>              Labels: GeodeCommons
>             Fix For: 1.11.0
>
>          Time Spent: 2h 40m
>  Remaining Estimate: 0h
>
> When using security, the OQL method authorizer is instantiated multiple times during
the OQL execuion, incurring into a waste of time and resources.
>  The authorizer is obtained through the {{queryContext.getCache().getQueryService().getMethodInvocationAuthorizer()}}
method, which basically creates a new instance of the {{DefaultQueryService}} and, also, a
new instance of the {{MethodInvocationAuthorizer}} configured:
> {code:java|title=DefaultQueryService.java|borderStyle=solid}
> public DefaultQueryService(InternalCache cache) {
>   if (cache == null)
>       throw new IllegalArgumentException("cache must not be null");
>   this.cache = cache;
>   if (!cache.getSecurityService().isIntegratedSecurity() || ALLOW_UNTRUSTED_METHOD_INVOCATION)
{
>     // A no-op authorizer, allow method invocation
>     this.methodInvocationAuthorizer = ((Method m, Object t) -> true);
>   } else {
>     this.methodInvocationAuthorizer = new RestrictedMethodAuthorizer(cache);
>   }
> }
> {code}
> When using implicit method invocation, the above implies that the authorizer will be
created X times per query, being X the amount of attributes accessed per object multiplied
by the amount of objects traversed by the query. As an example, if we have a region with 100
entries (entry has a non-public {{name}} attribute with a public {{getName()}} accessor) and
we execute {{SELECT o.name FROM /Region o}}, the {{MethodInvocationAuthorizer}} will be instantiated
100 times.
>  When using explicit method invocation things are "better": the {{MethodInvocationAuthorizer}}
is only created once for every new (unknown) method during the lifetime of the Geode member,
and that's basically because the {{MethodDispatch}} class is internally cached and it also
has the {{MethodInvocationAuthorizer}} used when it was created stored internally. This incurs
into another problem: once a {{MethodDispatch}} is created, the {{MethodInvocationAuthorizer}}
can't be changed, the user needs to restart the member in order to clear the cache ({{CompiledOperation}})
and force the query engine to execute a new lookup of the now unknown method (which must also
be done through the API when implementing GEODE-6991, otherwise changes won't be applied).
>  The {{MethodInvocationAuthorizer}} should be unique and unchangeable during the execution
of a particular query on a particular member, so we should investigate whether it would make
sense to create it only once at the beginning of the query execution and have it directly
available as part of the {{QueryExecutionContext}}.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Mime
View raw message