Apache TinkerPop•4mo ago

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:

java.util.concurrent.ExecutionException: org.apache.tinkerpop.gremlin.driver.exception.ResponseException: Failed to authorize: This AuthorizationHandler only handles requests with OPS_BYTECODE or OPS_EVAL.

java.util.concurrent.ExecutionException: org.apache.tinkerpop.gremlin.driver.exception.ResponseException: Failed to authorize: This AuthorizationHandler only handles requests with OPS_BYTECODE or OPS_EVAL.

And on the server side I see (full server log enclosed):

[INFO] o.a.t.g.s.h.WebSocketAuthorizationHandler - User stephen with address 127.0.0.1:53187 attempted an unauthorized request for close operation: null

[INFO] o.a.t.g.s.h.WebSocketAuthorizationHandler - User stephen with address 127.0.0.1:53187 attempted an unauthorized request for close operation: null

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:

:remote connect tinkerpop.server conf/remote-pw.yaml session
:remote console

:remote connect tinkerpop.server conf/remote-pw.yaml session
:remote console

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.

AllowListAuthorizer....

remote-pw.yaml

gremlin-server.log

gremlin-server-moder...

Solution:

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

Jump to solution

8 Replies

Yang Xia•4mo ago

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?

pm_osc•4mo ago

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.

Lyndon•4mo ago

Any movement on this? It seems similar to the issue I think I found Looks like authentication is garbling traversal arguments

Kennh•4mo ago

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.

Kennh•4mo ago

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.

pm_osc•3mo ago

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.

from gremlin_python.process.anonymous_traversal import traversal
from gremlin_python.driver.driver_remote_connection import DriverRemoteConnection

g = traversal().withRemote(DriverRemoteConnection('ws://localhost:8182/gremlin', 'g', username='stephen', password='password'))

# create a transaction
tx = g.tx()

# spawn a new GraphTraversalSource, binding all traversals established from it to tx.
gtx = tx.begin()

try:
  # execute a traversal within the transaction.
  gtx.addV().property('name', 'test1').property('age', 11)
  # commit the transaction
  tx.commit()
except Exception as e:
  print(e)
  # rollback the transaction if an error occurs
  tx.rollback()

from gremlin_python.process.anonymous_traversal import traversal
from gremlin_python.driver.driver_remote_connection import DriverRemoteConnection

g = traversal().withRemote(DriverRemoteConnection('ws://localhost:8182/gremlin', 'g', username='stephen', password='password'))

# create a transaction
tx = g.tx()

# spawn a new GraphTraversalSource, binding all traversals established from it to tx.
gtx = tx.begin()

try:
  # execute a traversal within the transaction.
  gtx.addV().property('name', 'test1').property('age', 11)
  # commit the transaction
  tx.commit()
except Exception as e:
  print(e)
  # rollback the transaction if an error occurs
  tx.rollback()

Thank you.

Solution

Kennh•3mo ago

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

pm_osc•3mo ago

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.

Gaming

Programming

Authorization with transaction results in error