Thank you for your response.
Suggestion regarding switching to persistent queues looks interesting. I'm
wondering what is the performance penalty of having
auto-delete-queues/auto-delete-addresses enabled on a broker with tens of
thousands of queues versus using temporary queues? Currently we have tens of
thousands of durable queues + max one temporary queue per every durable queue
acting as a replyTo queue (not all temporary queues exist at all times
obviously). If performance impact is considerable, can it be alleviated, by
let's say, enabling auto-delete-queues/auto-delete-addresses only on replyTo
queues?
--
Vilius
-----Original Message-----
From: Justin Bertram <jbert...@apache.org>
Sent: Friday, April 4, 2025 5:18 PM
To: users@activemq.apache.org
Subject: Re: how to separate permissions for replyTo temporary queues
> <security-setting
match="^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$">
I would not expect this syntax to work. The match for a security-setting must
conform to the wildcard syntax [1] which specifically states:
...wildcard characters cannot be used like wildcards in a regular
expression.
> Are we doing something wrong? Should we just rely on the fact that it
would be very difficult to guess other temp queue names?
I don't think you're doing anything _wrong_ per se. If you want to use
temporary queues then this is a trade-off you'll have to make.
However, if you really want to lock everything down then I recommend you don't
use temporary queues and just let the broker deal with automatically creating
and deleting the queues. You can name the queues with a particular prefix and
assign permissions to roles as appropriate, e.g.:
<address-settings>
...
<address-setting match="replyTo.#">
<auto-create-queues>true</auto-create-queues>
<auto-delete-queues>true</auto-delete-queues>
<auto-create-addresses>true</auto-create-addresses>
<auto-delete-addresses>true</auto-delete-addresses>
<address-setting>
...
</address-settings>
...
<security-settings>
...
<security-setting match="replyTo.app1.#">
<permission type="send" roles="app1" />
<permission type="consume" roles="app1" />
</security-setting>
<security-setting match="replyTo.app2.#">
<permission type="send" roles="app2" />
<permission type="consume" roles="app2" />
</security-setting>
...
</security-settings>
Then each of your applications could use something like this:
...
Session replyTo = session.createQueue("replyTo.app1." +
java.util.UUID.randomUUID().toString())
...
message.setJMSReplyTo(replyTo);
...
This is all off the top of my head so there might be some errors in there, but
hopefully you get the idea. Let me know if you have further questions!
Justin
[1]
https://activemq.apache.org/components/artemis/documentation/latest/wildcard-syntax.html#wildcard-syntax
On Fri, Apr 4, 2025 at 8:14 AM Vilius Šumskas
<vilius.sums...@rivile.lt.invalid> wrote:
> Hello,
>
> I’m wondering how one separates permissions of two different roles for
> temporary replyTo queues? Let’s say we have two external users which
> can consume from their durable queues, but they respond to replyTo
> queue created by producer (RPC flow model). We can only set one
> namespace for the queue and limit these users by:
>
> <temporary-queue-namespace>temp</temporary-queue-namespace>
> <security-setting match="temp.#">
> <permission type="send" roles="roleofbothusers" /> </security-setting>
>
> Or we could do:
>
> <security-setting
> match="^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0
> -9a-fA-F]{12}$"> <permission type="send" roles=" roleofbothusers " />
> </security-setting>
>
> But this doesn’t forbit user1 to send messages to temporary queues of
> user2. ReplyTo queues obviously have just random IDs and there is no
> way to differentiate between user1 temporary queues and user2 temporary
> queues.
>
> Are we doing something wrong? Should we just rely on the fact that it
> would be very difficult to guess other temp queue names?
>
> --
> Best Regards,
>
> Vilius Šumskas
> Rivile
> IT manager
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@activemq.apache.org
For additional commands, e-mail: users-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
