[
https://issues.apache.org/jira/browse/BOOKKEEPER-959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15610975#comment-15610975
]
ASF GitHub Bot commented on BOOKKEEPER-959:
-------------------------------------------
Github user eolivelli commented on the issue:
https://github.com/apache/bookkeeper/pull/67
Thanks @merlimat for the review.
Do you think we can remove the use of the "extensions" and use a field for
the payload ?
At least for the transition from no-auth to auth I can submit a fix on this
PR or is it better to create a new JIRA ?
my idea is to make the Bookie answer a standard message
"authentication-disabled" to clients which is trying to make any kind of auth,
so:
- on the server side the connection goes to "authenticated" state
- on the client side falls back to a "authenticated" state
this standard message will be processed from BookKeeper client system code
and not passed to the auth plugin
we have to implement a "require.authentication" flag on the Bookie side, to
let the admin set it to false, in order to deal with legacy clients (and
Bookies) which do not perform authentication.
On a rolling restart we upgrade Bookie to the new version with
require.authentication=false, then upgrade all the clients to the new version
and/or auth plugin, then we restart again each Bookie ith
require.authentication=true
this simple implementation will allow to switch from no-auth to auth, but
not from auth-1-plugin to auth-2-plugin
does it sound good ?
> ClientAuthProvider and BookieAuthProvider Public API used Protobuf Shaded
> classes
> ---------------------------------------------------------------------------------
>
> Key: BOOKKEEPER-959
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-959
> Project: Bookkeeper
> Issue Type: Bug
> Components: bookkeeper-client, bookkeeper-server
> Affects Versions: 4.4.0
> Reporter: Enrico Olivelli
> Assignee: Enrico Olivelli
> Priority: Blocker
> Fix For: 4.5.0
>
>
> With 4.4.0 we introduced the ability to implement custom authentication
> plugins.
> The new interfaces ClientAuthProvider and BookieAuthProvider depend on
> ExtensionRegistry, which is a shaded dependency.
> As a consequence it is not possibile to implement any custom auth provider in
> code outside the project, because shaded/relocated dependencies cannot be
> used.
> We need to break the actual interface and introduce a new way to implement
> such plugins in a portable way
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
