[
https://issues.apache.org/jira/browse/GEODE-4819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16418287#comment-16418287
]
ASF subversion and git services commented on GEODE-4819:
--------------------------------------------------------
Commit f9b16e937c94a93f1b1b2899ca43f5b1ebe76cc8 in geode's branch
refs/heads/develop from [~geodeintegration]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=f9b16e9 ]
GEODE-4819: Separating authorization out from protobuf handlers (#1674)
Separating out authentication from the logic of parsing protobuf
messages. All region operations should be done through the new
AuthenticatingCache API, which does authentication and the operation.
In a future change we should move AuthenticationCache to the core and
refactor gfsh, the REST API, and the old client to also go through this
layer.
> Protobuf authorization state check needs to be refactored
> ---------------------------------------------------------
>
> Key: GEODE-4819
> URL: https://issues.apache.org/jira/browse/GEODE-4819
> Project: Geode
> Issue Type: New Feature
> Components: client/server
> Reporter: Brian Rowe
> Priority: Major
> Labels: pull-request-available
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> The original authorization flow for the protobuf (in the
> ProtobufConnectionAuthorizingStateProcessor) would simply check whether the
> user had the permission statically defined in the operations context and then
> pass it to the handler if the check passed (doing the appropriate thread
> local modifications in the state processor call). With fine grained
> permissions, we now generally have to have the operator parse out the
> relevant fields to even determine the permission required. The batch
> operations are even worse in this regard as we'll potentially make many
> authorization requests and need to handle the failures individually, which
> forces us to include some level of nasty thread local management in the
> handler itself (making it very easy to introduce bugs if this isn't done
> correctly). We should reevaluate how we make the authorization calls and see
> if theres a more straightforward, less error-prone approach we can use.
> Bonus points if we can push this down into some intermediate object
> implementing the Region interface which can also be used by the old protocol
> and REST API.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
