Hi Matt, So yeah that's pretty much what I'm trying to figure out as well, or more specifically why it is looking for that pattern instead of the actual configured pattern. To better explain the scenario, there's 2 versions of the app, V1 & V2. They look like this:
V1: - Consumes from Consumer.user1.VirtualTopic.> - broker ACL says allow all V2: - Consumes from Consumer.user1.VirtualTopic.topic1 - broker ACL only allows specific queue. Upon deploy of V2, we got the error I mentioned below: 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 You can see in this error that the application side knows the right destination, but ActiveMQ is giving an error about the original destination. The only reason I can think it would do this is because the same client ID is in use from V1 of the application (that was deployed) and since that subscription was durable I need to first cycle through and remove the original connection and then I can add the necessary ACL to limit what I can connect to. More likely than not, V1 of the app was still running on some node so when ActiveMQ saw the connection from V2 using the same consumer. John On 2023/05/26 22:19:42 Matt Pavlovich wrote: > 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 > >
