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

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

Commit 85c67b2294c7e24534e2a2b4c68fecef812b4199 in geode's branch 
refs/heads/develop from [~bschuchardt]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=85c67b2 ]

GEODE-4819: Separating authorization out from protobuf handlers

Removed unused imports that were causing compilation warnings


> 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
>            Assignee: Dan Smith
>            Priority: Major
>              Labels: pull-request-available
>             Fix For: 1.6.0
>
>          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)

Reply via email to