You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@bookkeeper.apache.org by Enrico Olivelli <eo...@gmail.com> on 2016/10/19 15:02:33 UTC
How to implement a custom Auth Provider
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.ExtensionRegistry 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.GenericCallback<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.
>>> }
>>>
>>> }
>>>
>>>
>>>
>>>
>>>
Re: How to implement a custom Auth Provider
Posted by 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.
>> }
>>
>> }
>>
>>
>>
>>
>>
Re: How to implement a custom Auth Provider
Posted by 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 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.
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.
- 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 Sijie Guo <si...@apache.org>.
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.
- 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.ExtensionRegistry 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.GenericCallback<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 Sijie Guo <si...@apache.org>.
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.ExtensionRegistry 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.GenericCallback<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.
> }
>
> }
>