Hi John- I suggest double checking how the client is configuring the name of the wildcard queue. Is it in an XML or JSON file? A properties file? Most likely, there is some encoding problem and the broker is trying to authorize against the literal 'queue://Consumer.user1.VirtualTopic.\u003e’ vs the intended 'queue://Consumer.user1.VirtualTopic.>'
-Matt > On May 26, 2023, at 9:11 PM, John D. Ament <johndam...@apache.org> wrote: > > 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 >> >>
