[
https://issues.apache.org/jira/browse/TINKERPOP-2389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17231582#comment-17231582
]
ASF GitHub Bot commented on TINKERPOP-2389:
-------------------------------------------
spmallette commented on pull request #1308:
URL: https://github.com/apache/tinkerpop/pull/1308#issuecomment-726841623
> I just discovered from the code comments that SubgraphStrategy has an
unusual implementation for concatenating two withStrategies() steps: the second
one simply supersedes the first one instead of &&-ing the predicates of the two
SubgraphStrategies as one would expect.
I'm not sure that we have any strategy that is designed in such a way that
more than one instance can be added. Even `OptionsStrategy` has special
handling such that calls to `with()` find the strategy first and modify it
rather than adding multiple instances with the expectation that they merge.
> Personally, I would not object against modifying the semantics of
SubgraphStrategy concatenation, thus introducing a breaking change. What is
your preference what to do and in what ticket/PR? I have not checked yet
whether &&-ing the predicates is easy to implement.
Perhaps we should make the implicit rule of a single strategy instance
explicit somehow. All strategies might not be mergeable as easily as say
`OptionsStrategy` so perhaps we could create an interface that provides a
method to merge them. If that interface isn't present on a strategy added more
than once we could raise an error. I don't know if `SubgraphStrategy` will
merge predicates well...i guess it would just wrap the predicate in `and()`?
That's already a really complex strategy...would hate to make it more so.
Created https://issues.apache.org/jira/browse/TINKERPOP-2473 for further
consideration/discussion.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
> Authorization support in TinkerPop
> ----------------------------------
>
> Key: TINKERPOP-2389
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2389
> Project: TinkerPop
> Issue Type: Improvement
> Components: server
> Affects Versions: 3.4.7
> Reporter: Shekhar Bansal
> Priority: Major
> Attachments: Screenshot 2020-06-25 at 15.15.04.png
>
>
> Use case:
> # Tinkerpop supports multiple graphs using a single API and admin might want
> to restrict access to some of the graphs.
> # Admin might want to restrict read/write access to certain users.
>
> Proposal
> Add read/write access restrictions at graph level. We can extend it to
> executing scripts by adding execute privileges.
>
> Changes required
> Add `authorizer` block similar to `authentication` block in yaml file
>
> {code:java}
> authorization: {
> authorizer:
> org.apache.tinkerpop.gremlin.server.authorization.AllowAllAuthorizer,
> authorizationHandler:
> org.apache.tinkerpop.gremlin.server.handler.SaslAuthorizationHandler,
> config: {
> }
> }{code}
>
> Authorization will be done only if authentication is enabled. Authentication
> is done at per session basis while authorization will be done for each and
> every request.
> In `SaslAuthorizationHandler` or `HttpAuthorizationHandler` query will be
> parsed and depending on the step instructions, the query will be marked as of
> type read or write and then privilege evaluation will be done by calling
> `isAccessAllowed` method of `Authorizer`
> {code:java}
> public interface Authorizer {
> /**
> * Whether or not the authorization requires check.
> * If false will not authorzie user.
> */
> public boolean requireAuthorization();
> /**
> * Setup is called once upon system startup to initialize the {@code
> Authorizer}.
> */
> public void setup(final Map<String, Object> config);
> /**
> * A "standard" authorization implementation
> */
> public boolean isAccessAllowed(AuthorizationRequest authorizationRequest)
> throws AuthorizationException;
> }
> {code}
> Access policies can be defined in tools like `Apache Ranger`, sample policy:
> !Screenshot 2020-06-25 at 15.15.04.png|width=1017,height=548!
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
