Hi John- The error message seems to indicate the app is using a wild card subscription (or getting one encoded funny), but the authz is named to a specific destinations
\u003e = “>" What you have should work fine, but there seems to be a coordination problem. Either the authz needs the “>” wild card, or the app as the name of the queue wrong. The app should not need to read from the topic at all. The queue acts as alternative to the durable topic subscription, so it shouldn’t register a durable subscription either. -Matt > On May 26, 2023, at 3:37 PM, John D. Ament <johndam...@apache.org> wrote: > > Hi there > > We're on "Classic" 5.17.2 and use VirtualTopics pretty heavily, due to some > external constraints can't use Artemis quite yet. I was wondering, is > there any guidance on setting up ACLs with VirtualTopics? > > Originally when we setup the connection, the application was connecting and > consuming from 'Consumer.user1.VirtualTopic.>' to get everything but we > realized it was pulling in messages that we shouldn't have been and are > trying to setup an ACL to limit what topics the consumer can read from. > The ACL ended up looking like this: > > <authorizationEntry read="user1" admin="user1" write="user1" > topic="VirtualTopic.topic1"/> > <authorizationEntry read="user1" admin="user1" write="user1" > queue="Consumer.user1.VirtualTopic.topic1"/> > <authorizationEntry read="user1" admin="user1" write="user1" > topic="ActiveMQ.Advisory.>"/> > > Even with this ACL in place, when reconnecting the app we get an error > (we're using spring): Setup of JMS message listener invoker failed for > destination 'Consumer.user1.VirtualTopic.topic1' - trying to recover. > Cause: User user1 is not authorized to read from: > queue://Consumer.user1.VirtualTopic.\u003e > > I'm not 100% sure but I believe this is because the subscription is durable > on reboot, and the old subscription was still in place. If so, is there a > way to remove the subscription? Or do we need to just restart with a client > ID? > > Thanks, > > John
