[
https://issues.apache.org/jira/browse/TINKERPOP-1657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15947588#comment-15947588
]
ASF GitHub Bot commented on TINKERPOP-1657:
-------------------------------------------
Github user spmallette commented on a diff in the pull request:
https://github.com/apache/tinkerpop/pull/583#discussion_r108741558
--- Diff:
gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/Settings.java
---
@@ -387,6 +387,18 @@ public SerializerSettings() {}
public String className = AllowAllAuthenticator.class.getName();
/**
+ * Enable audit logging of authenticated users and gremlin
evaluation requests.
+ */
+ public boolean enableAuditLog = false;
+
+ /**
+ * The fully qualified class name of the {@link
AuthenticationHandler} implementation.
+ * This class name will be used to load the implementation from
the classpath.
+ * Defaults to null when not specified.
+ */
+ public String handlerClassName = null;
--- End diff --
I tried to stay consistent in naming for classes in the config by going
with `className` where the key was representative of an object in a `Map` or
`List`, but now it kinda bites us as `authentication.className` is used for the
`Authenticator` when it now really should probably refer to the handler since
it is now configurable.
Here's an idea:
1. Rename `handlerClassName` to `authenticationHandler`
2. Overload `className` with `authenticator` - if `authenticator` is
present then ignore any value in `className`. Update all the yaml files to use
`authenticator`.
[Deprecate](http://tinkerpop.apache.org/docs/current/dev/developer/#_deprecation)
`AuthenticationSettings.className`.
> 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)
