tinkerpop-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GitBox <...@apache.org>
Subject [GitHub] [tinkerpop] vtslab edited a comment on pull request #1308: TINKERPOP-2389 WIP: Authorization support in TinkerPop
Date Sat, 14 Nov 2020 11:35:46 GMT

vtslab edited a comment on pull request #1308:
URL: https://github.com/apache/tinkerpop/pull/1308#issuecomment-726770564

   Another consideration is the authorization of OLAP requests (initially also mentioned by
@FlorianHockmann). For HadoopGraph it seems sufficient to give some users access and others
not. Here, one could use a new ComputerDenyStrategy.
   For TinkerGraphComputer and FulgoraGraphComputer that run inside the Gremlin Server instance,
OLAP also might be legitimate for some users, but here you would like to restrict the number
of workers that a client can request, e.g. to 4 to give some speed up with respect to OLTP,
but not drain the server. Here, one would rather have some WorkerRestrictStrategy. Of course,
the two could coincide if you allow for WorkerRestrictStrategy.build.set(0).create(). Any
   [Edited] we also have the scripEvaluationTimeout, but this does not seem to protect against
requesting a large number of computer workers.
   [2nd edit] There is also the VertexProgramStrategy that is inserted into the bytecode by
the withComputer() step automatically. This can be inspected by an Authorizer if it wants
to deny OLAP. So, my comments above are only relevant for consistency: one can configure a
GraphTraversalSource with a ReadOnlyStrategy, but there is no ComputerDenyStrategy. But forget
about the WorkerRestrictStrategy because restricting computer workers is better handled by
the Authorizer. 

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:

View raw message