[
https://issues.apache.org/jira/browse/TINKERPOP-1657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15941688#comment-15941688
]
ASF GitHub Bot commented on TINKERPOP-1657:
-------------------------------------------
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/583
Hi and thanks for contributing. In general, I like the concept of this pull
request, but I have some thoughts to share to get us both on the same page. I'd
thought about doing this when we first decided to get authentication in place.
I opted not to do it for at least a couple reasons that I can remember:
1. The `Channelizer` abstraction might be enough of an abstraction. It's
not complex by any means - the core of `HttpChannelizer` is 20 lines of easily
readable code. If someone doesn't want basic auth, then just write a new
`Channelizer` and done. Personally, I'm not sure I want to see us expand
different kinds of HTTP auth in TinkerPop so `HttpChannelizer` with basic auth
seems good enough.
2. The configuration system required further pollution of the root of the
configuration file. It bugs me that we don't have `Channelizer` specific
configurations - e.g. you had to add `httpAuthHandlerClassName` to `Settings`
and that value has nothing to do with anything other than `HttpChannelizer`. If
you were configured for web sockets it would just be ignored. Not saying that
we don't have that issue at hand now (as I think we do), but I didn't want to
continue to proliferate it.
Anyway, I'd had it in my mind that solving 2 would make 1 more palatable as
something to do, but 2 hasn't come around yet and unless there is a neat way to
do it, it will come in as a breaking change to the Gremlin Server configuration
file.
So that's the basic history on this direction for auth configuration -
thoughts?
> 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)
