Hi Justin,

Having pulled the code and run some tests I found that,

The good news is :

1. Can already override the Filter in beforeCreateConsumer() and verified
this works
2. Can already override message content & headers in beforeSend() as per
existing broker plugin example

What's missing in order to migrate my existing AMQv5 plugin :

1. Extend ServerSession/Impl to expose `List getUserRoles()` so that a
plugin can track users of interest based on role, by overriding
afterCreateSession() - unless there is an existing way to access this
information from a plugin? The roles would be defined in LDAP in production.

2. Extend the plugin architecture with a hook into
ServerSessionImpl.createAddress() to be able to override an address before
it is created. This is called directly from the AMQP interface not via
ActiveMQServerImpl like the existing plugin hooks. The clients subscribe to
what I call a generic "pseudo topic" like "subscription.1" which needs to
be mapped to a real topic string broker-side depending on the user's
content rights e.g. "foo.*.bar.#". This works if I override the address
name in a debugger.

I guess the next step is to raise a feature ticket for this?


Thanks again


Dave



On Thu, Feb 20, 2020 at 5:15 PM David Martin <dav...@qoritek.com> wrote:

> Hi Justin,
>
> Having done some analysis I think I need to do the following however it
> appears that QueueConfig is intended to be immutable so maybe point (3)
> below is undesirable. Alternatively beforeCreateQueue() could return
> QueueConfig (by default returning input param as-is) in order to be able to
> configure a new QueueConfig instance in the plugin.
>
>    1.  Add userRole() to QueueConfig returning String
>    2. Add userRole(String) to QueueConfig.Builder and call in
>    ActiveMQServerImpl.createQueue() - lookup userRole in
>    this.securityManager.configuration.roles
>    3. Add setAddress(String) and setFilter(Filter) to QueueConfig to be
>    able to override them
>    4. Override ActiveMQServerPlugin.beforeCreateQueue() to intercept if
>    queueConfig.userRole.equals("customer") to override address and filter
>
>
> Thanks for your advice so far -
>
> Dave
>
>
> On Sat, Feb 15, 2020 at 7:06 PM Justin Bertram <jbert...@apache.org>
> wrote:
>
>> Interceptors work on a per-protocol basis and the way they work for each
>> is
>> slightly different. I think you can do what you want for core clients
>> using
>> interceptors, but I don't think it will work for AMQP. AMQP interceptors
>> don't intercept low-level packets/frames like the other interceptors do
>> because Proton-J takes care of all the low-level work. Instead an AMQP
>> interceptor just intercepts incoming *messages* (i.e.
>> org.apache.activemq.artemis.protocol.amqp.broker.AMQPMessage instances).
>>
>> I think the solution for you would be to enhance the objects you want to
>> change so that you actually can (e.g. make variables non-final). When all
>> the implementation work was done originally a plugin infrastructure wasn't
>> even considered. As users want/need to do more with plugins we'll need to
>> change the code to allow it in certain places like this.
>>
>> Would you be willing to send a PR with the changes you need?
>>
>>
>> Justin
>>
>> On Sat, Feb 15, 2020 at 11:14 AM David Martin <dav...@qoritek.com> wrote:
>>
>> > Hi Justin,
>> >
>> > AMQP or Core - can be either
>> >
>> >
>> > Thanks,
>> >
>> > Dave
>> >
>> > On Fri, Feb 14, 2020, 11:02 PM Justin Bertram <jbert...@apache.org>
>> wrote:
>> >
>> > > What protocol are your clients going to be using?
>> > >
>> > >
>> > > Justin
>> > >
>> > > On Fri, Feb 14, 2020 at 3:28 PM David Martin <dav...@qoritek.com>
>> wrote:
>> > >
>> > > > Thanks Chris -
>> > > >
>> > > > Unfortunately what I need to override (queue name and filter) is
>> read
>> > > only:
>> > > >
>> > > >
>> > > >
>> > >
>> >
>> https://github.com/apache/activemq-artemis/blob/master/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/ConsumerInfo.java
>> > > >
>> > > > Wondering whether an interceptor is what I need? Unless I'm missing
>> > > > something blindingly obvious about these interfaces for plugins .
>> > > >
>> > > >
>> > > > Dave
>> > > >
>> > > > On Fri, Feb 14, 2020, 2:06 PM Christopher Shannon <
>> > > > christopher.l.shan...@gmail.com> wrote:
>> > > >
>> > > > > Take a look at the plugin API for Artemis:
>> > > > >
>> > > > >
>> > > >
>> > >
>> >
>> https://activemq.apache.org/components/artemis/documentation/latest/broker-plugins.html
>> > > > >
>> > > > > Specifically you can implement your own ActiveMQServerPlugin
>> (which
>> > > > extends
>> > > > > many other plugin interfaces) and has a ton of hooks into the
>> broker
>> > to
>> > > > do
>> > > > > what you need.  ActiveMQServerConsumerPlugin probably has the
>> methods
>> > > you
>> > > > > need.
>> > > > >
>> > > > >
>> > > > >
>> > > >
>> > >
>> >
>> https://github.com/apache/activemq-artemis/blob/master/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/plugin/ActiveMQServerConsumerPlugin.java
>> > > > >
>> > > > > On Thu, Feb 13, 2020 at 9:59 AM David Martin <dav...@qoritek.com>
>> > > wrote:
>> > > > >
>> > > > > > Hi everyone,
>> > > > > >
>> > > > > > Decided to switch to Artemis which is not going to be difficult
>> in
>> > > the
>> > > > > main
>> > > > > > but not sure of my best option to migrate a broker plugin which
>> > > > overrides
>> > > > > > *addConsumer()* to set a new destination and a message selector
>> > using
>> > > > > > broker-side business logic based on the user credentials. It
>> looks
>> > > > like I
>> > > > > > might be able to do this as a plugin or as an interceptor and
>> not
>> > > sure
>> > > > > what
>> > > > > > to override on either of these interfaces?
>> > > > > >
>> > > > > > Any help/pointers appreciated.
>> > > > > >
>> > > > > > Thanks,
>> > > > > >
>> > > > > > Dave
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>

Reply via email to