Note that there is some discussion on the "math" issue on the gremlin-users
mailing list:
https://groups.google.com/d/msg/gremlin-users/EFog3lhh4Xw/1VVi2c9J
On Wed, Sep 20, 2017 at 11:03 AM, Keith Lohnes wrote:
> I agree with Robert that the scripting-off option would work, but would
> ha
I agree with Robert that the scripting-off option would work, but would
have to be the default. I've run into people who aren't particularly happy
about having to `def` variables because we've enabled a sandbox. I think
saying, "These are not enabled by default" in the docs would be a
necessity. Be
Network security is out of scope. It's generally applicable. There's
nothing peculiar to Gremlin Server that would warrant its own section on
network security.
I could see where a security-first approach is taken and scripting would be
off by default. This forces the user to be somewhat more aware
>
> Like a good example of where I tend to get stuck with Gremlin is "math"
Exactly. It's mostly simple calculations using customer specific formulas.
Many calculations could be done using sack(), but .map { /* do the math */ }
is a) more flexible and b) faster as it's just a single step. String
It would be an option to turn off script processing, but if you're saying
that you believe that would almost never be possible (as most production
systems will use lambdas) then there probably isn't much point to adding
the option. Scripts will always just be there and users will have to
appropriat
>
> Obviously lambdas wouldn't work but that might be fine for many
> applications.
I would make a bet that lambdas are used in most production systems. When I
work with customers, I usually try to rewrite queries and prevent the use
of lambdas, but often there's simply no way to do the same thin
I just updated the reference docs for Gremlin Server to include some more
wording on security. I just wanted to make it more clear that Gremlin
Server executes arbitrary code. I like to think people get that and
understand the implications of what that means from a security perspective,
but
