I think this is likely _not_ a bug. I believe you're seeing the expected behavior. This is because authorization is checked when the consumer is created. So when you create the consumer and the proper security-setting is present then authorization succeeds. When you remove the relevant security-setting the consumer continues on receiving messages because it has already been authorized to do so. When the consumer is restarted then it must be reauthorized. Reauthorization fails because the proper security-setting is no longer present.
The broker could theoretically check authorization for every message dispatched to the consumer, but I think that would impose a relatively significant performance penalty for not much gain. If you want the ensure the security changes are enforced before the consumer reconnects on its own then you can just close the consumer administratively via the web console. Hope that helps! Justin On Mon, Feb 20, 2023 at 8:00 AM Thorsten Meinl <thorsten.me...@knime.com> wrote: > Hi, > > We recently observed a strange behaviour with Artemis (2.24) which > makes us wonder whether it's a bug. > We have an Artemis user that has one (or more) roles attached to it. > The role grants permissions to read a certain topic. Even after this > role has been deleted from Artemis the consumer is still being able to > consume messages from that topic. Only after the consumer is restarted > it is denied access. I would expect that changes to security settings > take effect more or less immediately and not only after consumers are > restarted. > > Regards, > > Thorsten > > -- > Dr.-Ing. Thorsten Meinl > KNIME AG > Talacker 50 > 8001 Zurich, Switzerland > > >
