Github user dkuppitz commented on the issue:
https://github.com/apache/tinkerpop/pull/534
VOTE: +1
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/534
ok @vtslab i won't do the work on merge then. i'm fine with letting it
happen with the gremlin-python work.
---
If your project is set up for it, you can reply to this email and have your
Github user vtslab commented on the issue:
https://github.com/apache/tinkerpop/pull/534
A good catch by @robertdale indeed, about the bytecode requests. I was not
even aware those were human readable. A proposal: include the audit logging of
bytecode requests in a new Jira ticket
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/534
ooo - well noted @robertdale - i'm fine with getting that added to
`TraversalOpProcessor` at a later date, but it shouldn't be forgotten. maybe
i'll just add that in when i go to merge this.
Github user vtslab commented on the issue:
https://github.com/apache/tinkerpop/pull/534
Thanks, Stephen, for guiding me through this so far. Once this gets merged,
I'd like to take a look at authentication with the python driver.
---
If your project is set up for it, you can reply
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/534
I sense that there could be some changes to LICENSE/NOTICE as a result of
this work. I will make changes to those files as necessary on merge. In the
mean time, the rest of this looks pretty
Github user mike-tr-adamson commented on the issue:
https://github.com/apache/tinkerpop/pull/534
I'm good with what's now there.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/534
sorry - i was good with whatever @mike-tr-adamson was down for. he
originally brought in the sasl stuff for tinkerpop, so i was glad he could take
a moment to review and comment on this. if
Github user vtslab commented on the issue:
https://github.com/apache/tinkerpop/pull/534
I interpreted almosta week of silence as consensus on the gremlin-driver
behavior, so I made the following changes:
- restored gremlin-driver's Handler (checkout from master)
- added a ToDo
Github user mike-tr-adamson commented on the issue:
https://github.com/apache/tinkerpop/pull/534
Hi @vtslab, the majority of SASL mechanisms that are suitable for this form
of authentication require some form of credential, be it token or certificate,
at the client end. I agree that
Github user vtslab commented on the issue:
https://github.com/apache/tinkerpop/pull/534
Hi @mike-tr-adamson, I am glad you entered the discussion. I think your
main point is valid, namely that there are circumstances, pointed out by you,
when gremlin-driver should select the GSSAPI
Github user mike-tr-adamson commented on the issue:
https://github.com/apache/tinkerpop/pull/534
I'm concerned about changing the `getMechanism` logic based on the failing
tests. The tests can legitimately fail both ways. It would be valid to fix
those tests so that they can fail on
Github user vtslab commented on the issue:
https://github.com/apache/tinkerpop/pull/534
OK, thanks, I'll see to it. The downside of the third option was implicit:
it changes the driver code which is in production everywhere. But that´s why
we do this work in the 3.3.x line and I
Github user vtslab commented on the issue:
https://github.com/apache/tinkerpop/pull/534
Hi, I am working on the two failing integration tests. It can be fixed in
three ways:
1. just hide the symptoms and also allow a GSSException for a test that
should fail anyway: ugly!
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/534
Well - looks like they are still broken. My favorite situation - they fail
with maven but pass in intellij. I suppose that has something to do with your
explanation regarding the classpath.
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/534
I'm not sure if TINKERPOP-1600 fixed it or if you did something in rebase,
but the two failing tests dont' seem to be a problem anymore when I run the
tests in intellij. As a result, I'm
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/534
Sorry - I'd forgotten you'd mentioned the broken tests. Ok - we'll figure
out what to do there once you rebase. Thanks for renaming the PR.
---
If your project is set up for it, you can reply
Github user vtslab commented on the issue:
https://github.com/apache/tinkerpop/pull/534
Yes, I mentioned these failing tests in the PR text above. I suspect that
the java security libs just pick up the krb5.conf file from the test resources
"without asking". It means the test fails
18 matches
Mail list logo
