You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bookkeeper.apache.org by Enrico Olivelli <eo...@gmail.com> on 2016/10/20 14:24:01 UTC
Re: How to implement a custom Auth Provider
I have just opened a PR with my proposal on
https://issues.apache.org/jira/browse/BOOKKEEPER-959
-- Enrico
2016-10-20 14:20 GMT+02:00 Enrico Olivelli <eo...@gmail.com>:
> Here it it the issue
> https://issues.apache.org/jira/browse/BOOKKEEPER-959
>
> I will share some code soon
>
> I'm working on a SASL implementation similar to ZooKeeper SASL
> implementation, in order to support oth MD5 and GSSAPI/Kerberos
> authentication
>
>
> 2016-10-20 0:37 GMT+02:00 Matteo Merli <mm...@yahoo-inc.com>:
>> Hi Enrico,
>>
>> yes the shading of protobuf is a bit of a problem. A possible solution would
>> be to include the implementation in BookKeeper itself, if it's of general
>> interest.
>>
>> Another approach, could be to release both shaded and unshaded jars for
>> bookkeeper-server artifact.
>
> I think we'd better to continue to shade protobuf, as it is a common
> library and introduces compatibility problems. (we have just upgraded
> to 2.6 which was compatibile only on the wire with previuos version)
>
>>
>>
>> Matteo
>>
>>
>> On Wednesday, October 19, 2016 9:41 AM, Sijie Guo <si...@apache.org> wrote:
>>
>>
>> I think we also need to think a solution on how to prevent this kind of
>> shade behavior. It is not good to expose shade classes to any public
>> interface.
>
> We should mark classes which are really part of the "Public API" (for
> instance with annotations) and then we can develop/use some tool to
> check the byte code
>
>
>>
>> - Sijie
>>
>> On Wed, Oct 19, 2016 at 9:40 AM, Sijie Guo <si...@apache.org> wrote:
>>
>> Ah, good catch, Enrico.
>>
>> It is really bad for this behavior. I think it should be fine to break the
>> code backward compatibility for this interface.
>>
>> - Sijie
>>
>> On Wed, Oct 19, 2016 at 8:02 AM, Enrico Olivelli <eo...@gmail.com>
>> wrote:
>>
>> Hi,
>> I'm going to implement a custom AuthProvider for BookKeeper, I have
>> come to a showstopper:
>> ClientAuthProvider.Factory depends on Protobuf ExtensionRegistry,
>> which is shaded inside the BooKeeper JAR
>>
>> A custom provider will look like the code below, this is not good,
>> because my code needs to depend on an "hidden" dependency of BK.
>>
>> I can file a JIRA and propose a fix, but any fix need to break
>> compatibilty with existing custom Providers (But I assume that no
>> implemention can actually exist, outside a fork of BookKeeper)
>>
>> What do you think ?
>>
>> This is an example
>>
>> public class CustomProvider implements ClientAuthProvider.Factory {
>>
>> @Override
>> public void init(ClientConfiguration cc,
>> bk-shade.com.google.protobuf.E xtensionRegistry er) throws IOException
>> {
>> throw new UnsupportedOperationException( "Not supported yet.");
>> //To change body of generated methods, choose Tools | Templates.
>> }
>>
>> @Override
>> public ClientAuthProvider newProvider(InetSocketAddress isa,
>> BookkeeperInternalCallbacks.Ge nericCallback<Void> gc) {
>> throw new UnsupportedOperationException( "Not supported yet.");
>> //To change body of generated methods, choose Tools | Templates.
>> }
>>
>> @Override
>> public String getPluginName() {
>> throw new UnsupportedOperationException( "Not supported yet.");
>> //To change body of generated methods, choose Tools | Templates.
>> }
>>
>> }
>>
>>
>>
>>
>>
Re: How to implement a custom Auth Provider
Posted by Enrico Olivelli <eo...@gmail.com>.
Just as a proof-of-concept I developed a simple
SASL/Md%-DIGEST/Kerberos Auth provider
https://github.com/eolivelli/bookkeeper/tree/BOOKKEEPER-391/bookkeeper-server/src/main/java/org/apache/bookkeeper/sasl
this is just a simple test, but it is very like to current ZooKeeper
implementation and the implementation I have on Majordodo and
BlazingCache projects
Enrico
2016-10-20 16:24 GMT+02:00 Enrico Olivelli <eo...@gmail.com>:
> I have just opened a PR with my proposal on
> https://issues.apache.org/jira/browse/BOOKKEEPER-959
>
> -- Enrico
>
> 2016-10-20 14:20 GMT+02:00 Enrico Olivelli <eo...@gmail.com>:
>> Here it it the issue
>> https://issues.apache.org/jira/browse/BOOKKEEPER-959
>>
>> I will share some code soon
>>
>> I'm working on a SASL implementation similar to ZooKeeper SASL
>> implementation, in order to support oth MD5 and GSSAPI/Kerberos
>> authentication
>>
>>
>> 2016-10-20 0:37 GMT+02:00 Matteo Merli <mm...@yahoo-inc.com>:
>>> Hi Enrico,
>>>
>>> yes the shading of protobuf is a bit of a problem. A possible solution would
>>> be to include the implementation in BookKeeper itself, if it's of general
>>> interest.
>>>
>>> Another approach, could be to release both shaded and unshaded jars for
>>> bookkeeper-server artifact.
>>
>> I think we'd better to continue to shade protobuf, as it is a common
>> library and introduces compatibility problems. (we have just upgraded
>> to 2.6 which was compatibile only on the wire with previuos version)
>>
>>>
>>>
>>> Matteo
>>>
>>>
>>> On Wednesday, October 19, 2016 9:41 AM, Sijie Guo <si...@apache.org> wrote:
>>>
>>>
>>> I think we also need to think a solution on how to prevent this kind of
>>> shade behavior. It is not good to expose shade classes to any public
>>> interface.
>>
>> We should mark classes which are really part of the "Public API" (for
>> instance with annotations) and then we can develop/use some tool to
>> check the byte code
>>
>>
>>>
>>> - Sijie
>>>
>>> On Wed, Oct 19, 2016 at 9:40 AM, Sijie Guo <si...@apache.org> wrote:
>>>
>>> Ah, good catch, Enrico.
>>>
>>> It is really bad for this behavior. I think it should be fine to break the
>>> code backward compatibility for this interface.
>>>
>>> - Sijie
>>>
>>> On Wed, Oct 19, 2016 at 8:02 AM, Enrico Olivelli <eo...@gmail.com>
>>> wrote:
>>>
>>> Hi,
>>> I'm going to implement a custom AuthProvider for BookKeeper, I have
>>> come to a showstopper:
>>> ClientAuthProvider.Factory depends on Protobuf ExtensionRegistry,
>>> which is shaded inside the BooKeeper JAR
>>>
>>> A custom provider will look like the code below, this is not good,
>>> because my code needs to depend on an "hidden" dependency of BK.
>>>
>>> I can file a JIRA and propose a fix, but any fix need to break
>>> compatibilty with existing custom Providers (But I assume that no
>>> implemention can actually exist, outside a fork of BookKeeper)
>>>
>>> What do you think ?
>>>
>>> This is an example
>>>
>>> public class CustomProvider implements ClientAuthProvider.Factory {
>>>
>>> @Override
>>> public void init(ClientConfiguration cc,
>>> bk-shade.com.google.protobuf.E xtensionRegistry er) throws IOException
>>> {
>>> throw new UnsupportedOperationException( "Not supported yet.");
>>> //To change body of generated methods, choose Tools | Templates.
>>> }
>>>
>>> @Override
>>> public ClientAuthProvider newProvider(InetSocketAddress isa,
>>> BookkeeperInternalCallbacks.Ge nericCallback<Void> gc) {
>>> throw new UnsupportedOperationException( "Not supported yet.");
>>> //To change body of generated methods, choose Tools | Templates.
>>> }
>>>
>>> @Override
>>> public String getPluginName() {
>>> throw new UnsupportedOperationException( "Not supported yet.");
>>> //To change body of generated methods, choose Tools | Templates.
>>> }
>>>
>>> }
>>>
>>>
>>>
>>>
>>>