ReadOnlyStrategy for remote script execution to make a read only server instance
Hi all, I am setting up a read only cluster of gremlin server, I have conifgured the initialization script like this:
globals << [g : traversal().withEmbedded(graph).withStrategies(ReferenceElementStrategy)]
Now when I'm using g and sending a write request to the gremlin server I'm getting the proper exception and not able to add data.
The issue I'm facing is that I can access the graph instance directly and able to send request like graph.traversal().addV() in place of g.addV, is there a way I can restrict this and make the server only accept write request? TIA.8 Replies
If you are using JanusGraph, you can set
storage.read-only = true
In general, I am not sure but maybe try not exposing graph to users?Hi @boxuanli Yes I have configured
storage.read-only = true but I was curious if the same can be achieved using strategies.
Can you please tell me more about how can I not expose the graph instance to users? The graph instance is not getting set in global variable in the initialixzation script on server start.i don't think there is a way to not expose the
Graph instance.@shivam.choudhary - i should have added that if you'd like to see this feature, please feel free to create a JIRA, i do think it is a good one that the server should probably have.
Sure, let me go through the guideline and will create one but there's one more thing I found that with
g also I can override the ReadOnlyStrategy set during initialisation by using withoutStrategies(ReadOnlyStrategy) configuration.
This is mentioned in the doc which I missed initially: https://tinkerpop.apache.org/docs/current/reference/#configuration-steps-withoutstrategiesyeah, it's more of a "check" than a solid mechanism for preventing writes. you probably need to rely on the features of graphs themselves to try to control that. i'm not sure we can easily implement that well in TinkerPop across all graphs. we're just at the wrong layer to do that really well. i do think that hiding the
Graph instance isn't a bad thing to do and configuring g to be static in some way (so that you can't remove strategies) aren't bad features to have .Yeah makes sense, thanks for the clarification
It just occured to me that you could use Authorization functions in Gremlin server to block traversals that have mutating steps: https://tinkerpop.apache.org/docs/current/reference/#authorization