Authorization with transaction results in error
Hi All, I have configured passive authorization as described in https://tinkerpop.apache.org/docs/3.7.0/reference/#authorization. All works fine, but once I use Gremlin console with session mode, calling
:remote close
, the following error happens:
And on the server side I see (full server log enclosed):
In my real setup, I use gremlin-python and JanusGraph to create nodes in a transaction and once tx.commit()
is called the same error happens. I just wanted to provide a minimal reproducible example hence I used Gremlin console with :remote close
One can reproduce the issue as follows:
1. download Gremlin Server 3.7.0 and unzip
2. use enclosed gremlin-server-modern-with-auth.yaml
and put into conf
folder
3. create an AllowListAuthorizer.java
(enclosed) and copy it to the gremlin server folder (next to lib
folder):
4. compile the Java file: javac -cp lib/gremlin-core-3.7.0.jar:lib/gremlin-server-3.7.0.jar:lib/gremlin-util-3.7.0.jar:lib/slf4j-api-1.7.33.jar -d . *.java
5. create jar: jar -cf authz.jar org/yourpackage/AllowListAuthorizer.class
6. copy the authz.jar
to lib
folder
4. start Gremlin server with: bin/gremlin-server.sh conf/gremlin-server-modern-with-auth.yaml
6. download gremlin-console-3.7.0, and add a file called remote-pw.yaml
under conf
folder (enclosed)
7. start gremlin console with bin/gremlin.sh
and execute:
8. execute g.V().valueMap()
to see the data
9. execute :remote close
to get the above exception
I hope to get some help what could be wrong. Thank you.Solution:Jump to solution
I've looked into your real use case a little closer and I don't think there's a workaround at this time. Side note, you should end your traversals with a terminating step like iterate() or else they don't do anything. So your query should actually be
gtx.addV().property('name', 'test1').property('age', 11).iterate()
. The error you are seeing with "This AuthorizationHandler..." occurs after the transaction attempts to commit so it shouldn't actually prevent the commit from occurring. The real p...GitHub
TINKERPOP-3081 Fix traversal argument propagation under authenticat...
Issue is that when using authentication traversal arguments (for example evaluationTimeout do not propagate, leading to failures in the traversal and unexpected behavior. This fixes that problem
8 Replies
Thanks for providing the information. I don't think I've seen this error, so I'll have to take a closer look at your set up to replicate first. You are seeing the same error in both JanusGraph and Gremlin Server, correct?
Thank you for your message. Yes, with JanusGraph 1.0 and Gremlin Server 3.7.0, I see the very same error, that is why I think this is related to Gremlin Server and not JanusGraph specific issue. Thanks.
Any movement on this? It seems similar to the issue I think I found
Looks like authentication is garbling traversal arguments
Sorry, it looks like no one's had a chance to look into this yet. I'll try to reproduce this issue tomorrow and get back to you with some more detailed information.
Thanks for providing such a detailed repro case.
This is caused by a bug in the server. The auth handler doesn't properly take care of the "close" request sent from the driver (which the Console uses internally). If you're interested, this is the line that causes it https://github.com/apache/tinkerpop/blob/3.7.0/gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/handler/WebSocketAuthorizationHandler.java#L83 . It's a bit more complicated than simply adding support for it in the auth handler because the "close" request was supposed to be have deprecated back in 3.3.11 but it was brought back into the driver after. I guess I'm trying to say there isn't actually a simple and complete fix even though the cause of the issue is obvious.
If you need to use sessions directly, then I don't think there are any current workarounds. However, it sounds like you just want to use transactions, depending on how you use transactions, and whether your rely on autocommit/autorollback, we might be able to find a workaround.
GitHub
tinkerpop/gremlin-server/src/main/java/org/apache/tinkerpop/gremlin...
Apache TinkerPop - a graph computing framework. Contribute to apache/tinkerpop development by creating an account on GitHub.
Thanks a lot @Kennh for looking into this. You are right, our main goal is to be able to use transaction in Gremlin Python. Please see the below Python code snippet for reproducing the "This AuthorizationHandler only handles requests with OPS_BYTECODE or OPS_EVAL." error with our real use case.
Before running the snippet, gremlinpython 3.7.0 package needs to be installed.
Thank you.
Solution
I've looked into your real use case a little closer and I don't think there's a workaround at this time. Side note, you should end your traversals with a terminating step like iterate() or else they don't do anything. So your query should actually be
gtx.addV().property('name', 'test1').property('age', 11).iterate()
. The error you are seeing with "This AuthorizationHandler..." occurs after the transaction attempts to commit so it shouldn't actually prevent the commit from occurring. The real problem you will encounter is a different server issue that Lyndon was alluding to earlier. The problem is that the authorization handler on the server is accidentally converting the request from the client from a session request (which is used for transactions on the server side) to a regular request. Lyndon actually has a proposed fix for this https://github.com/apache/tinkerpop/pull/2622/files . This fix should go into the next release, but I'm not sure when that release will happen. Lately, there has been a quarterly release cadence so it hopefully shouldn't be too far off.GitHub
TINKERPOP-3081 Fix traversal argument propagation under authenticat...
Issue is that when using authentication traversal arguments (for example evaluationTimeout do not propagate, leading to failures in the traversal and unexpected behavior. This fixes that problem
Thanks a lot @Kennh for your help on this. Indeed, I missed the iterate() step when I converted our real scenario into a simplified one. Thank you for the background information on this and thanks to Lyndon for the proposed fix.