[
https://issues.apache.org/jira/browse/TINKERPOP-1657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15943396#comment-15943396
]
ASF GitHub Bot commented on TINKERPOP-1657:
-------------------------------------------
Github user krlohnes commented on the issue:
https://github.com/apache/tinkerpop/pull/583
You make some very good points.
> The Channelizer abstraction might be enough of an abstraction.
I'd thought about that a bit, but in general, I'd rather not have to
rewrite (or worse, essentially copy and paste) a piece of OS code that works
almost exactly like I need it to, but simply doesn't have an extension point
where there could easily be one.
>Personally, I'm not sure I want to see us expand different kinds of HTTP
auth in TinkerPop
I'm not suggesting adding additional "out of the box" authorization
schemes, which is why I didn't commit one. I'm really only suggesting making
Tinkerpop more easily extensible so users can code their own that fits with
their orgs current auth schemes/security requirements.
> If you were configured for web sockets it would just be ignored
I think this abstraction could be applied fairly easily to the
`WebSocketsChannelizer`. There's already the `SaslAuthenticationHandler` there.
I think that with a similar change to the ternary operator in the
`SaslAuthenicationHandler.init` as in the HttpChannelizer.init, you could
change the abstract `HttpAuthenticationHandler` class to an
`AuthenticationHandler` and have the `SaslAuthenticationHandler` extend that. I
could then change the config name from `httpAuthHandlerClassName` to
`authHandlerClassName`.
> The configuration system required further pollution of the root of the
configuration file
Well, it's not the _root_ of the configuration file. It's under
`authentication : { ... }`.
I do agree that Channelizer config would be nice to have and may follow
naturally from the idea of this PR, but I think this PR is a small, iterative
change that _doesn't_ break anything.
I think with the change around the `WebSocketsChannelizer` (included in a
new commit), the story around this becomes better. Let me know what you think.
> Provide abstraction to easily allow different HttpAuth schemes
> --------------------------------------------------------------
>
> Key: TINKERPOP-1657
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1657
> Project: TinkerPop
> Issue Type: Improvement
> Components: server
> Reporter: Keith Lohnes
>
> The current HttpChannelizer allows for extension through an Authenticator
> class supplied through the authorization settings. There isn't, however, an
> extension point for an authentication handler. Currently the choice is
> between the `AllowAllAuthenticator` or the `HttpBasicAuthenticationHandler`.
> One would need to create a new channelizer where the HttpChannelizer would
> suffice. Creating an abstract class that can be extended would make it easier
> to extend Authentication for things like token authentication schemes.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
