I think it's necessary to mention the target versions in the proposal. I'd say that this proposal shouldn't go into branch-3.0 since it breaks existing implementations of the AuthorizationProvider interface. This could be avoided by providing a compatible default implementation of the interface method that delegates to the existing method. I searched open-source repositories for implementations, and it seems that there's at least https://github.com/CleverCloud/biscuit-pulsar, which implements the AuthorizationProvider interface.
-Lari On Fri, 27 Sept 2024 at 11:12, Baodi Shi <ba...@apache.org> wrote: > > +1 > > @lari For this type of improved API, which is clearer and more > decoupled, can we include it in version 3.3? > > Thanks, > Baodi Shi > > Lari Hotari <lhot...@apache.org> 于2024年9月27日周五 00:42写道： > > > > Thanks for driving this Jiwei. > > This will be useful in addressing the current challenge with concurrent > > modifications. > > Is this targeted for Pulsar 4.0? > > > > -Lari > > > > On 2024/09/26 14:04:35 guo jiwei wrote: > > > Hello, > > > > > > I have created a PIP for supporting granting/revoking permissions for > > > multiple topics. > > > > > > In AuthorizationProvider, the authorization interface > > > `grantPermissionAsync(TopicName topicName, Set<AuthAction> actions, String > > > role, String authDataJson)` currently only supports granting permissions > > > to > > > a single topic. > > > If multiple topics need to be authorized under a namespace, the client > > > needs to call the authorization interface concurrently. > > > Since the permissions information are stored in the namespace-level > > > policies, and multiple topics may be on different brokers, concurrent > > > authorization will cause concurrent modification exceptions. > > > Therefore, supporting granting/revoking permissions for multiple topics is > > > very friendly. > > > > > > PIP-383: https://github.com/apache/pulsar/pull/23355 > > > > > > Regards > > > Jiwei Guo (Tboy) > > >
