[jira] [Commented] (TINKERPOP-1600) Consistent use of base 64 encoded bytes for SASL negotiation
[
https://issues.apache.org/jira/browse/TINKERPOP-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15825589#comment-15825589
]
ASF GitHub Bot commented on TINKERPOP-1600:
---
Github user vtslab commented on the issue:
https://github.com/apache/tinkerpop/pull/533
While this solves the issue for byte[] returned from Sasl, I can still
crash the driver by adding a byte[] as a vertex property and ask for the result:
gremlin> g.V(1).property('test1', 'test1' as byte[])
==>v[1]
gremlin> g.V(1).values('test1')
==>[116, 101, 115, 116, 49]
gremlin> g.V(1).values('test1').next().getClass()
==>class [B
OK, this is a pathological example, why configure serializeResultToString
if you want a byte[] returned... BTW, what is this serializeResultToString
meant for anyway?
> Consistent use of base 64 encoded bytes for SASL negotiation
>
>
> Key: TINKERPOP-1600
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1600
> Project: TinkerPop
> Issue Type: Improvement
> Components: driver, server
>Affects Versions: 3.2.3
>Reporter: stephen mallette
>Assignee: stephen mallette
> Fix For: 3.2.4
>
>
> Gremlin Server currently uses a mix of base 64 encoded bytes and byte arrays
> for SASL negotiation. This can cause problems for certain serializers (like
> toString serialization with gryo) as the byte array won't be respected. In an
> effort to easily support virtually any serializer a switch to using just base
> 64 string is probably best.
> This can be done in such a way as to be backward compatible. The base64 SASL
> value will be returned in the response message status attributes map in a key
> called "sasl". The original byte array will continue to be returned in the
> response message result. Eventually, we could phase out the byte array in the
> result - perhaps with 3.3.0.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] tinkerpop issue #533: TINKERPOP-1600 Added base64 encoded string to sasl cha...
Github user vtslab commented on the issue:
https://github.com/apache/tinkerpop/pull/533
While this solves the issue for byte[] returned from Sasl, I can still
crash the driver by adding a byte[] as a vertex property and ask for the result:
gremlin> g.V(1).property('test1', 'test1' as byte[])
==>v[1]
gremlin> g.V(1).values('test1')
==>[116, 101, 115, 116, 49]
gremlin> g.V(1).values('test1').next().getClass()
==>class [B
OK, this is a pathological example, why configure serializeResultToString
if you want a byte[] returned... BTW, what is this serializeResultToString
meant for anyway?
---
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 the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Commented] (TINKERPOP-1601) LazyBarrierStrategy should not check is.testing
[
https://issues.apache.org/jira/browse/TINKERPOP-1601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15824836#comment-15824836
]
ASF GitHub Bot commented on TINKERPOP-1601:
---
GitHub user dkuppitz opened a pull request:
https://github.com/apache/tinkerpop/pull/535
TINKERPOP-1601 LazyBarrierStrategy should not check is.testing
https://issues.apache.org/jira/browse/TINKERPOP-1601
Only a minor improvement (strategies shouldn't behave differently depending
on whether we're in testing mode or not). If a test requires that certain
strategies don't do anything, then it's the test's job to exclude those
strategies.
`docker/build.sh -t -i` succeeded.
VOTE: +1
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/apache/tinkerpop TINKERPOP-1601
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/tinkerpop/pull/535.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #535
commit 0edf2e929b244055720d0e2054f21caef2205cc1
Author: Daniel Kuppitz
Date: 2017-01-16T19:21:24Z
Removed IS_TESTING check from LazyBarrierStrategy.
commit 3179f6dab9065206a811e124c7827d4d9c5211ad
Author: Daniel Kuppitz
Date: 2017-01-17T01:43:41Z
fixed assertion
commit ff844904df2b9e5d48c4725e8679f139c0e463e0
Author: Daniel Kuppitz
Date: 2017-01-17T01:44:13Z
Changed btecode representation of excluded strategies to prevent
serialization issues.
> LazyBarrierStrategy should not check is.testing
> ---
>
> Key: TINKERPOP-1601
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1601
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.3
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>
> {{LazyBarrierStrategy}} should not check the value if the system variable
> {{is.testing}} and then behave differently depending on its value. The
> cleaner way is to just exclude {{LBS}} in {{ProfileTest}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] tinkerpop pull request #535: TINKERPOP-1601 LazyBarrierStrategy should not c...
GitHub user dkuppitz opened a pull request: https://github.com/apache/tinkerpop/pull/535 TINKERPOP-1601 LazyBarrierStrategy should not check is.testing https://issues.apache.org/jira/browse/TINKERPOP-1601 Only a minor improvement (strategies shouldn't behave differently depending on whether we're in testing mode or not). If a test requires that certain strategies don't do anything, then it's the test's job to exclude those strategies. `docker/build.sh -t -i` succeeded. VOTE: +1 You can merge this pull request into a Git repository by running: $ git pull https://github.com/apache/tinkerpop TINKERPOP-1601 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/tinkerpop/pull/535.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #535 commit 0edf2e929b244055720d0e2054f21caef2205cc1 Author: Daniel Kuppitz Date: 2017-01-16T19:21:24Z Removed IS_TESTING check from LazyBarrierStrategy. commit 3179f6dab9065206a811e124c7827d4d9c5211ad Author: Daniel Kuppitz Date: 2017-01-17T01:43:41Z fixed assertion commit ff844904df2b9e5d48c4725e8679f139c0e463e0 Author: Daniel Kuppitz Date: 2017-01-17T01:44:13Z Changed btecode representation of excluded strategies to prevent serialization issues. --- 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 the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (TINKERPOP-1600) Consistent use of base 64 encoded bytes for SASL negotiation
[ https://issues.apache.org/jira/browse/TINKERPOP-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15824605#comment-15824605 ] ASF GitHub Bot commented on TINKERPOP-1600: --- Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/533 ah - cool. i think that i kinda needed your changes so that i could better test this PR. perhaps I can get mine merged in first, then you can rebase yours with these changes. > Consistent use of base 64 encoded bytes for SASL negotiation > > > Key: TINKERPOP-1600 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1600 > Project: TinkerPop > Issue Type: Improvement > Components: driver, server >Affects Versions: 3.2.3 >Reporter: stephen mallette >Assignee: stephen mallette > Fix For: 3.2.4 > > > Gremlin Server currently uses a mix of base 64 encoded bytes and byte arrays > for SASL negotiation. This can cause problems for certain serializers (like > toString serialization with gryo) as the byte array won't be respected. In an > effort to easily support virtually any serializer a switch to using just base > 64 string is probably best. > This can be done in such a way as to be backward compatible. The base64 SASL > value will be returned in the response message status attributes map in a key > called "sasl". The original byte array will continue to be returned in the > response message result. Eventually, we could phase out the byte array in the > result - perhaps with 3.3.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] tinkerpop issue #533: TINKERPOP-1600 Added base64 encoded string to sasl cha...
Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/533 ah - cool. i think that i kinda needed your changes so that i could better test this PR. perhaps I can get mine merged in first, then you can rebase yours with these changes. --- 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 the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (TINKERPOP-1600) Consistent use of base 64 encoded bytes for SASL negotiation
[ https://issues.apache.org/jira/browse/TINKERPOP-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15824593#comment-15824593 ] ASF GitHub Bot commented on TINKERPOP-1600: --- Github user vtslab commented on the issue: https://github.com/apache/tinkerpop/pull/533 This attacks the same issue as I had in PR TINKERPOP-1566 Kerberos: [https://github.com/apache/tinkerpop/pull/534/commits/62648242c6576b020d2dd2933b89b9d69e87fed0] I am fine with your solution in TINKERPOP-1600. > Consistent use of base 64 encoded bytes for SASL negotiation > > > Key: TINKERPOP-1600 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1600 > Project: TinkerPop > Issue Type: Improvement > Components: driver, server >Affects Versions: 3.2.3 >Reporter: stephen mallette >Assignee: stephen mallette > Fix For: 3.2.4 > > > Gremlin Server currently uses a mix of base 64 encoded bytes and byte arrays > for SASL negotiation. This can cause problems for certain serializers (like > toString serialization with gryo) as the byte array won't be respected. In an > effort to easily support virtually any serializer a switch to using just base > 64 string is probably best. > This can be done in such a way as to be backward compatible. The base64 SASL > value will be returned in the response message status attributes map in a key > called "sasl". The original byte array will continue to be returned in the > response message result. Eventually, we could phase out the byte array in the > result - perhaps with 3.3.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] tinkerpop pull request #532: TINKERPOP-1601 LazyBarrierStrategy should not c...
Github user dkuppitz closed the pull request at: https://github.com/apache/tinkerpop/pull/532 --- 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 the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] tinkerpop issue #533: TINKERPOP-1600 Added base64 encoded string to sasl cha...
Github user vtslab commented on the issue: https://github.com/apache/tinkerpop/pull/533 This attacks the same issue as I had in PR TINKERPOP-1566 Kerberos: [https://github.com/apache/tinkerpop/pull/534/commits/62648242c6576b020d2dd2933b89b9d69e87fed0] I am fine with your solution in TINKERPOP-1600. --- 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 the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (TINKERPOP-1601) LazyBarrierStrategy should not check is.testing
[
https://issues.apache.org/jira/browse/TINKERPOP-1601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15824594#comment-15824594
]
ASF GitHub Bot commented on TINKERPOP-1601:
---
Github user dkuppitz closed the pull request at:
https://github.com/apache/tinkerpop/pull/532
> LazyBarrierStrategy should not check is.testing
> ---
>
> Key: TINKERPOP-1601
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1601
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.3
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>
> {{LazyBarrierStrategy}} should not check the value if the system variable
> {{is.testing}} and then behave differently depending on its value. The
> cleaner way is to just exclude {{LBS}} in {{ProfileTest}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TINKERPOP-1566) Kerberos authentication for gremlin-server
[ https://issues.apache.org/jira/browse/TINKERPOP-1566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15824585#comment-15824585 ] ASF GitHub Bot commented on TINKERPOP-1566: --- Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/534 Thanks for this - Could you please update the name of the pull request to be: "TINKERPOP-1566 Kerberos" - basically we just need the JIRA identifier in the prefix of the name so that it hooks up into the JIRA automation. > Kerberos authentication for gremlin-server > -- > > Key: TINKERPOP-1566 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1566 > Project: TinkerPop > Issue Type: Improvement > Components: server >Reporter: Marc de Lignie >Priority: Minor > Labels: security > Fix For: 3.3.0 > > > Gremlin server would benefit from an explicit Kerberos authentication plugin, > because preparing and maintaining such a plugin is nontrivial. Also, many > other Apache project provide kerberized services. > In gremlin-console the standard Krb5LoginModule can be configured. > Gremlin-server already includes the pluggable Sasl framework that can host > the proposed Kerberos authentication plugin. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] tinkerpop issue #534: Tinkerpop 1566
Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/534 Thanks for this - Could you please update the name of the pull request to be: "TINKERPOP-1566 Kerberos" - basically we just need the JIRA identifier in the prefix of the name so that it hooks up into the JIRA automation. --- 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 the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] tinkerpop pull request #534: Tinkerpop 1566
GitHub user vtslab opened a pull request: https://github.com/apache/tinkerpop/pull/534 Tinkerpop 1566 This PR includes three items (as stated in the changelog): 1 Added Kerberos authentication to `gremlin-server` for websockets and nio transport. 2 Added audit logging of authenticated users and of gremlin queries to `gremlin-server`. 3 Fixed `gremlin-driver`'s support for string results regarding returned byte arrays from `Sasl` authentication. Regarding item 1, I did not attempt to provide Kerberos authentication for http transport, as I assumed http will not be very popular anymore, now that the GLV's are available for accessing graphs via gremlin-server. Item 2, audit logging, naturally belongs to Kerberos authentication. Kerberos is important in providing access to confidential data, that is, being sure of someone's identity without having him logging in for each service. Some confidential data, like personal data, often have legal obligations regarding logging of their access: that is what item 2 provides. Item 3 is just a minor issue that surfaced during test development of Kerberos authentication. An ample number of integration tests is provided. In addition, I did manual tests in a working freeIPA Kerberos environment to verify the proper working. Reviewers wanting a short reminder of Kerberos authenticationb are referred to: http://www.roguelynn.com/words/explain-like-im-5-kerberos/ [It learnt me a lot, I am not trying to be arrogant :-)] The main design choices I made are: i) Krb5Authenticator does not refer to policy servers or storage backends for authorization, but rather assumes that any user who can be authenticated using Kerberos, is also authorized to access the service. Others could extend on this. ii) The JAAS entry for Krb5Authenticator was not made configurable, apart from the principal name and keytab location to be provided in the yaml file. Using a separate JAAS config file would primarily introduce more flexibility in getting the config wrong. This choice is in line with the current situation with all authenticator configuration in gremlin-server's yaml file. But the choice is not consistent with other Apache projects like Hadoop and HBase. iii) Audit logging was made into a general feature that also works for other authenticators. It has to be explicitly enabled, though, with a property in gremlin-server's yaml file, because the audit logs can contain confidential data. iv) Audit logging was given a separate logger apart from the org.apache.tinkerpop naming tree, so that its level can be set to INFO without influencing level settings of the normal logging. The logger name, "audit.org.apache.tinkerpop.gremlin.server", was defined in GremlinServer, for lack of a better location. v) Apache Kerby was used as the Kerberos Key Distribution Center (KDC) for the Kerberos integration tests, because it also belongs to Apache and proved easy to use. The project is still in RC2 status, though, but is only a test dependency. Finally, running integration test on gremlin-server still results in two errors, probably due to the presence of the gremlinjaas.conf file in the test resources. I did not correct these, because I was not sure whether it could be due to my test environment. Failed tests: GremlinServerAuthIntegrateTest.shouldFailAuthenticateWithPlainTextNoCredentials:130 expected: but was: GremlinServerAuthOldIntegrateTest.shouldFailAuthenticateWithPlainTextNoCredentials:133 expected: but was: You can merge this pull request into a Git repository by running: $ git pull https://github.com/vtslab/incubator-tinkerpop TINKERPOP-1566 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/tinkerpop/pull/534.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #534 commit f09546e8bf61d0fc5ab5d92568ee9e7b6e86773e Author: vtslab Date: 2016-11-25T10:48:32Z Kerberos authenticator files added commit 0f43649f86fcf049a5d2749387f832d2ed71fa9f Author: vtslab Date: 2016-11-28T12:16:51Z Added failing test shouldAuthenticateWithSerializeResultToString commit d874207fb2f53139cc131012a866b3c271a0f73f Author: HadoopMarc Date: 2016-12-03T15:41:47Z Fixed problem with non-lowercase hostname commit debb7c854a9a3042f091f5751182b2f563151f1e Author: HadoopMarc Date: 2016-12-04T15:14:05Z Added Kerberos tests for client commit cb81fcfbc968c09bee4ac4ab059adf4782df037d Author: HadoopMarc Date: 2016-12-11T10:15:29Z Added Krb5Authenticator to reference docs commit ab157645d4d5db986eb0cf3
[GitHub] tinkerpop issue #503: Fixed and simplified 'language not supported' formatti...
Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/503 @joshsh think you might come back to this pull request any time soon? --- 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 the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] tinkerpop issue #529: TINKERPOP-1549 Implement skip()
Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/529 All tests pass with `docker/build.sh -t -n -i` 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 the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (TINKERPOP-1549) Implement skip()
[
https://issues.apache.org/jira/browse/TINKERPOP-1549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15824568#comment-15824568
]
ASF GitHub Bot commented on TINKERPOP-1549:
---
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/529
All tests pass with `docker/build.sh -t -n -i`
VOTE +1
> Implement skip()
>
>
> Key: TINKERPOP-1549
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1549
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>
> We should have a {{.skip(x)}} and {{.skip(local, x)}}. The functionality is
> already provided by {{RangeStep}} ({{.range(x, -1)}} skips {{x}} elements and
> emits the remainder).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] tinkerpop issue #531: Added more recipes
Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/531 Thanks for all the feedback. I've pushed some changes on this branch given the comments I've seen. I think I got all of it. Good to vote now? --- 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 the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (TINKERPOP-1600) Consistent use of base 64 encoded bytes for SASL negotiation
[ https://issues.apache.org/jira/browse/TINKERPOP-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15824553#comment-15824553 ] ASF GitHub Bot commented on TINKERPOP-1600: --- GitHub user spmallette opened a pull request: https://github.com/apache/tinkerpop/pull/533 TINKERPOP-1600 Added base64 encoded string to sasl challenge This is a small change but I was hoping for some tests by driver providers before merging as this change messes with the authentication scheme a bit. It should be a backward compatible change, but I just wanted to be sure I didn't break anything before merging this. VOTE +1 You can merge this pull request into a Git repository by running: $ git pull https://github.com/apache/tinkerpop TINKERPOP-1600 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/tinkerpop/pull/533.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #533 commit 0fcb306efa05c21b9c11f25f5dddb658159a4540 Author: Stephen Mallette Date: 2017-01-16T20:22:07Z TINKERPOP-1600 Added base64 encoded string to sasl challenge > Consistent use of base 64 encoded bytes for SASL negotiation > > > Key: TINKERPOP-1600 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1600 > Project: TinkerPop > Issue Type: Improvement > Components: driver, server >Affects Versions: 3.2.3 >Reporter: stephen mallette >Assignee: stephen mallette > Fix For: 3.2.4 > > > Gremlin Server currently uses a mix of base 64 encoded bytes and byte arrays > for SASL negotiation. This can cause problems for certain serializers (like > toString serialization with gryo) as the byte array won't be respected. In an > effort to easily support virtually any serializer a switch to using just base > 64 string is probably best. > This can be done in such a way as to be backward compatible. The base64 SASL > value will be returned in the response message status attributes map in a key > called "sasl". The original byte array will continue to be returned in the > response message result. Eventually, we could phase out the byte array in the > result - perhaps with 3.3.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] tinkerpop pull request #533: TINKERPOP-1600 Added base64 encoded string to s...
GitHub user spmallette opened a pull request: https://github.com/apache/tinkerpop/pull/533 TINKERPOP-1600 Added base64 encoded string to sasl challenge This is a small change but I was hoping for some tests by driver providers before merging as this change messes with the authentication scheme a bit. It should be a backward compatible change, but I just wanted to be sure I didn't break anything before merging this. VOTE +1 You can merge this pull request into a Git repository by running: $ git pull https://github.com/apache/tinkerpop TINKERPOP-1600 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/tinkerpop/pull/533.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #533 commit 0fcb306efa05c21b9c11f25f5dddb658159a4540 Author: Stephen Mallette Date: 2017-01-16T20:22:07Z TINKERPOP-1600 Added base64 encoded string to sasl challenge --- 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 the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (TINKERPOP-1601) LazyBarrierStrategy should not check is.testing
[
https://issues.apache.org/jira/browse/TINKERPOP-1601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15824467#comment-15824467
]
ASF GitHub Bot commented on TINKERPOP-1601:
---
GitHub user dkuppitz opened a pull request:
https://github.com/apache/tinkerpop/pull/532
TINKERPOP-1601 LazyBarrierStrategy should not check is.testing
https://issues.apache.org/jira/browse/TINKERPOP-1601
Only a minor improvement (strategies shouldn't behave differently depending
on whether we're in testing mode or not). If a test requires that certain
strategies don't do anything, then it's the test's job to exclude those
strategies.
VOTE: +1
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/apache/tinkerpop TINKERPOP-1601
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/tinkerpop/pull/532.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #532
commit 0edf2e929b244055720d0e2054f21caef2205cc1
Author: Daniel Kuppitz
Date: 2017-01-16T19:21:24Z
Removed IS_TESTING check from LazyBarrierStrategy.
> LazyBarrierStrategy should not check is.testing
> ---
>
> Key: TINKERPOP-1601
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1601
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.3
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>
> {{LazyBarrierStrategy}} should not check the value if the system variable
> {{is.testing}} and then behave differently depending on its value. The
> cleaner way is to just exclude {{LBS}} in {{ProfileTest}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] tinkerpop pull request #532: TINKERPOP-1601 LazyBarrierStrategy should not c...
GitHub user dkuppitz opened a pull request: https://github.com/apache/tinkerpop/pull/532 TINKERPOP-1601 LazyBarrierStrategy should not check is.testing https://issues.apache.org/jira/browse/TINKERPOP-1601 Only a minor improvement (strategies shouldn't behave differently depending on whether we're in testing mode or not). If a test requires that certain strategies don't do anything, then it's the test's job to exclude those strategies. VOTE: +1 You can merge this pull request into a Git repository by running: $ git pull https://github.com/apache/tinkerpop TINKERPOP-1601 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/tinkerpop/pull/532.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #532 commit 0edf2e929b244055720d0e2054f21caef2205cc1 Author: Daniel Kuppitz Date: 2017-01-16T19:21:24Z Removed IS_TESTING check from LazyBarrierStrategy. --- 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 the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (TINKERPOP-1566) Kerberos authentication for gremlin-server
[ https://issues.apache.org/jira/browse/TINKERPOP-1566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15824460#comment-15824460 ] Marc de Lignie commented on TINKERPOP-1566: --- I am in the rebase and final testing phase. Hope it won't take too long anymore. > Kerberos authentication for gremlin-server > -- > > Key: TINKERPOP-1566 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1566 > Project: TinkerPop > Issue Type: Improvement > Components: server >Reporter: Marc de Lignie >Priority: Minor > Labels: security > Fix For: 3.3.0 > > > Gremlin server would benefit from an explicit Kerberos authentication plugin, > because preparing and maintaining such a plugin is nontrivial. Also, many > other Apache project provide kerberized services. > In gremlin-console the standard Krb5LoginModule can be configured. > Gremlin-server already includes the pluggable Sasl framework that can host > the proposed Kerberos authentication plugin. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TINKERPOP-1601) LazyBarrierStrategy should not check is.testing
Daniel Kuppitz created TINKERPOP-1601:
-
Summary: LazyBarrierStrategy should not check is.testing
Key: TINKERPOP-1601
URL: https://issues.apache.org/jira/browse/TINKERPOP-1601
Project: TinkerPop
Issue Type: Improvement
Components: process
Affects Versions: 3.2.3
Reporter: Daniel Kuppitz
Assignee: Daniel Kuppitz
{{LazyBarrierStrategy}} should not check the value if the system variable
{{is.testing}} and then behave differently depending on its value. The cleaner
way is to just exclude {{LBS}} in {{ProfileTest}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TINKERPOP-1599) implement real gremlin-python driver
[
https://issues.apache.org/jira/browse/TINKERPOP-1599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15824354#comment-15824354
]
stephen mallette commented on TINKERPOP-1599:
-
I gave it a quick look. I see that you moved a couple of public classes around.
I assume that is a breaking change. If you feel like some reorganization was
needed here, I think you should "deprecate" the old classes and keep them where
they are (i'm assuming there is a way to mark code as deprecated in python)
then introduce the new ones elsewhere. I think it's good that we have an actual
"driver" now for python. It will be good to start to see the python driver
begin to get similar features to the java one. Thanks for doing that.
> implement real gremlin-python driver
>
>
> Key: TINKERPOP-1599
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1599
> Project: TinkerPop
> Issue Type: Improvement
> Components: driver, language-variant
>Affects Versions: 3.2.3
>Reporter: David M. Brown
>Assignee: David M. Brown
> Fix For: 3.3.0
>
>
> It is high time that gremlin-python comes packaged with a real driver. After
> watching the community discussion, it seems that the way to go will be to use
> the {{concurrent.futures}} module with multithreading to provide asynchronous
> I/O. While the default underlying websocket client library will remain
> Tornado due to Python 2/3 compatibility issues, this should be decoupled from
> the rest of the client and easy to replace.
> With this is mind, I created a baseline client implementation with [this
> commit|https://github.com/apache/tinkerpop/commit/fb7e7f255585956abbb854fcc5dd3138113cf454]
> in a topic branch {{python_driver}}. Some things to note:
> - All I/O is performed using the {{concurrent.futures}} module, which
> provides a standard 2/3 compatible future interface.
> - The implementation currently does not include the concept of a cluster,
> instead it assumes a single host.
> - The {{transport}} interface makes it easy to plug in client libraries by
> defining a simple wrapper.
> - Because this is an example, I didn't fix all the tests to work with the new
> client implementation. Instead I just added a few demo tests. If we decide to
> move forward with this I will update the original tests.
> The resulting API looks like this for a simple client:
> {code}
> client = Client('ws://localhost:8182/gremlin', 'g')
> g = Graph().traversal()
> t = g.V()
> future_result_set = client.submitAsync(t.bytecode)
> result_set = future_result_set.result()
> results = result_set.all().result()
> client.close()
> {code}
> Using the {{DriverRemoteConnection}}:
> {code}
> conn = DriverRemoteConnection('ws://localhost:8182/gremlin', 'g')
> g = Graph().traversal().withRemote(conn)
> t = g.V()
> results = t.toList()
> conn.close()
> {code}
> If you have a minute to check out the new driver code that would be great, I
> welcome feedback and suggestions. If we decide to move forward like this, I
> will proceed to finish the driver implementation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TINKERPOP-1599) implement real gremlin-python driver
[
https://issues.apache.org/jira/browse/TINKERPOP-1599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15824219#comment-15824219
]
David M. Brown commented on TINKERPOP-1599:
---
I've made a few small fixes since I first pushed this code. It would probably
be better to see the changes [in comparison
mode|https://github.com/apache/tinkerpop/compare/python_driver].
> implement real gremlin-python driver
>
>
> Key: TINKERPOP-1599
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1599
> Project: TinkerPop
> Issue Type: Improvement
> Components: driver, language-variant
>Affects Versions: 3.2.3
>Reporter: David M. Brown
>Assignee: David M. Brown
> Fix For: 3.3.0
>
>
> It is high time that gremlin-python comes packaged with a real driver. After
> watching the community discussion, it seems that the way to go will be to use
> the {{concurrent.futures}} module with multithreading to provide asynchronous
> I/O. While the default underlying websocket client library will remain
> Tornado due to Python 2/3 compatibility issues, this should be decoupled from
> the rest of the client and easy to replace.
> With this is mind, I created a baseline client implementation with [this
> commit|https://github.com/apache/tinkerpop/commit/fb7e7f255585956abbb854fcc5dd3138113cf454]
> in a topic branch {{python_driver}}. Some things to note:
> - All I/O is performed using the {{concurrent.futures}} module, which
> provides a standard 2/3 compatible future interface.
> - The implementation currently does not include the concept of a cluster,
> instead it assumes a single host.
> - The {{transport}} interface makes it easy to plug in client libraries by
> defining a simple wrapper.
> - Because this is an example, I didn't fix all the tests to work with the new
> client implementation. Instead I just added a few demo tests. If we decide to
> move forward with this I will update the original tests.
> The resulting API looks like this for a simple client:
> {code}
> client = Client('ws://localhost:8182/gremlin', 'g')
> g = Graph().traversal()
> t = g.V()
> future_result_set = client.submitAsync(t.bytecode)
> result_set = future_result_set.result()
> results = result_set.all().result()
> client.close()
> {code}
> Using the {{DriverRemoteConnection}}:
> {code}
> conn = DriverRemoteConnection('ws://localhost:8182/gremlin', 'g')
> g = Graph().traversal().withRemote(conn)
> t = g.V()
> results = t.toList()
> conn.close()
> {code}
> If you have a minute to check out the new driver code that would be great, I
> welcome feedback and suggestions. If we decide to move forward like this, I
> will proceed to finish the driver implementation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TINKERPOP-1600) Consistent use of base 64 encoded bytes for SASL negotiation
stephen mallette created TINKERPOP-1600: --- Summary: Consistent use of base 64 encoded bytes for SASL negotiation Key: TINKERPOP-1600 URL: https://issues.apache.org/jira/browse/TINKERPOP-1600 Project: TinkerPop Issue Type: Improvement Components: driver, server Affects Versions: 3.2.3 Reporter: stephen mallette Assignee: stephen mallette Fix For: 3.2.4 Gremlin Server currently uses a mix of base 64 encoded bytes and byte arrays for SASL negotiation. This can cause problems for certain serializers (like toString serialization with gryo) as the byte array won't be respected. In an effort to easily support virtually any serializer a switch to using just base 64 string is probably best. This can be done in such a way as to be backward compatible. The base64 SASL value will be returned in the response message status attributes map in a key called "sasl". The original byte array will continue to be returned in the response message result. Eventually, we could phase out the byte array in the result - perhaps with 3.3.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TINKERPOP-1574) Get rid of untyped GraphSON 3.0
[ https://issues.apache.org/jira/browse/TINKERPOP-1574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-1574: Labels: (was: breaking) > Get rid of untyped GraphSON 3.0 > --- > > Key: TINKERPOP-1574 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1574 > Project: TinkerPop > Issue Type: Improvement > Components: io >Affects Versions: 3.2.3 >Reporter: Marko A. Rodriguez > Fix For: 3.3.0 > > > We should not have GraphSON 2.0 untyped. Too many degrees of freedom. > GraphSON should be GraphSON typed and thats that. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TINKERPOP-1574) Get rid of untyped GraphSON 3.0
[ https://issues.apache.org/jira/browse/TINKERPOP-1574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-1574: Summary: Get rid of untyped GraphSON 3.0 (was: Get rid of untyped GraphSON 2.0) GraphSON 2.0 won't change its format so as to not create a breaking change. This will happen for 3.0. > Get rid of untyped GraphSON 3.0 > --- > > Key: TINKERPOP-1574 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1574 > Project: TinkerPop > Issue Type: Improvement > Components: io >Affects Versions: 3.2.3 >Reporter: Marko A. Rodriguez > Fix For: 3.3.0 > > > We should not have GraphSON 2.0 untyped. Too many degrees of freedom. > GraphSON should be GraphSON typed and thats that. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
