Hi Vilius,
If the name of the subscription queue is known, you can create security
setting for FQQN queue name, for example
"address-for-external-role::queue-for-subscription".
чт, 17 апр. 2025 г. в 09:42, Vilius Šumskas
:
> I would like to rephrase my question regarding createDurableQueue
>
The createDurableQueue permission is required for JMS durable subscribers
(i.e. consumers) since the durable subscription they create is represented
by a durable, multicast queue. The name of the queue is based on the client
ID & subscription name provided by the client.
Sending a message to the J
> Do these clients need to be of a particular version, or is native
redirection implemented using native protocol specification. E.g. any AMQP
0.9 client will work?
Just to avoid any confusion...AMQP 0.9 isn't supported. Only 1.0 is
supported.
Justin
On Fri, Apr 18, 2025 at 6:14 AM Vilius Šumsk
Very cool. Sometimes I'm amazed how flexible Artemis is!
To be able to deploy 100% working scenario to production, because of
https://issues.apache.org/jira/browse/ARTEMIS-5439 , I will have to wait for
the next Artemis release, but thank you again for the help.
--
Vilius
-Original Me
Severity: moderate
Affected versions:
- Apache ActiveMQ NMS OpenWire Client before 2.1.1
Description:
Deserialization of Untrusted Data vulnerability in Apache ActiveMQ NMS OpenWire
Client.
This issue affects Apache ActiveMQ NMS OpenWire Client before 2.1.1 when
performing connections to unt
Yes, I understood these options. I would definitely prefer #3 as this takes
permissions from external user completely, but would you advice going this way
or it could be a complicated solution in a sense like "building a house from
sticks" :) ?
--
Vilius
-Original Message-
From:
There are different ways to lock down the broker.
1) You can make it so that external clients can only create exactly the
subscription queue(s) you allow them to create by defining
security-settings with the FQQN (i.e.
::.). This, of course, requires
you to know the client ID and subscription na
The current implementation doesn't allow combining different key types in
one router.
In your case, the native router redirection is not used. The redirection
allows to redirect a client connection to another target broker.
In your case, the connection router is used to reject connections that
don'
I guess that makes sense. If client ID and subscription name is known in
advance, would you advise to create queues via management API in disabled state
and then enable after consumer comes online, like suggested by Alexander?
--
Vilius
-Original Message-
From: Justin Bertram
Sen
Thank you. It is working very well! Couple more questions:
* Is it possible to combine different key types in one router? For example,
have connections checked for USER_NAME or ROLE_NAME if user name is not found?
* Documentation mentions that native router redirection works for specific
clients.
10 matches
Mail list logo
