[
https://issues.apache.org/jira/browse/TINKERPOP-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15247581#comment-15247581
]
ASF GitHub Bot commented on TINKERPOP-1263:
-------------------------------------------
Github user mike-tr-adamson commented on the pull request:
https://github.com/apache/incubator-tinkerpop/pull/291#issuecomment-211867447
I have changed the ```Handler::channelRead0``` to add the mechanism as an
argument to the initial SASL message. These means that the
```SaslAuthenticationHandler``` is now unchanged.
I agree that this is a more elegant solution and allows 3rd party auth
implementations to use or not use the mechanism at their leisure. Note that it
is down to the auth implementation to handle the case of no mechanism being
passed. It shouldn't be a requirement.
> Pass SASL mechanism name through with initial SASL response
> -----------------------------------------------------------
>
> Key: TINKERPOP-1263
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1263
> Project: TinkerPop
> Issue Type: Improvement
> Components: driver
> Affects Versions: 3.1.2-incubating
> Reporter: Mike Adamson
> Assignee: stephen mallette
> Fix For: 3.1.3, 3.2.1
>
>
> Support was added to the client driver to allow either plain text or GSSAPI
> SASL authentication. This improvement is for the client to pass the name of
> the mechanism as part of the initial SASL response. This gives the server
> side SASL handler the option to negotiate whether it will allow the specific
> mechanism.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
