[
https://issues.apache.org/jira/browse/TINKERPOP-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15245855#comment-15245855
]
ASF GitHub Bot commented on TINKERPOP-1263:
-------------------------------------------
Github user PommeVerte commented on the pull request:
https://github.com/apache/incubator-tinkerpop/pull/291#issuecomment-211433503
Hey Mike. Sounds fair enough. I wasn't pointing fingers, just wanted to
understand the thought process a bit better.
Just to explicit what I meant by the difference between prepending and
adding. The payload is constructed of a `wrapper` which is basically a `byte`
and a `mimetype` at this point for binary payloads. And a `message` to be
deserialized (via `GraphSONMessageSerializer`, `GryoMessageSerializer`, etc.).
Prepending is basically adding the mechanism to the `wrapper`.
Adding would be including it in the `message` as an argument. Along side
the `sasl` credential argument for example (or some other variation)
The difference here is that with the curent implementation, existing
drivers will need to be upgraded to support this feature change in the payload,
along the lines of the changes you made in this PR on the Java Driver.
The first point here is that this can be an issue with drivers that
separate the `wrapper` building logic from the `message` building. ie: the
`wrapper` is always built the same way and reused for all operations. Adding
the mechanism for _only_ the authentication `message` becomes a special use
case in the `wrapper`. Depending on the implementation this can either get
ugly, or be less trivial than expected. (`PHP`, `javascript` and `python`
drivers fall in this category)
The second point is that if the mechanism were included as a `message`
argument instead, then most drivers out there either already support this
feature or have mechanisms in place to extend authentication `message`
building. So we basically provide the feature keys in hand for users of those
drivers. And if the drivers really have no support for what was just mentioned,
it's a trivial upgrade.
I tried to keep this clear but it's not one of my fortes. Let me know if it
wasn't clear, or if there's some conflicting logic in implementing this in the
message rather than the wrapper.
Cheers.
> 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)
