It seems a bit naive of a customer to expect the broker to not rely upon or
leverage features of the operating system, but I digress.
Are you tied to ActiveMQ 5.x or could you also use ActiveMQ Artemis?
Artemis already has a timeout which will disconnect clients that don't send
any data for a prot
In theory, yes, an iptables or firewalld approach would work.
But certain customers doing pen-testing require the solution to be
self-sufficient, so I'll need
this kind of access control as part of the listen-accept logic of the ActiveMQ
broker.
- Martin
On 02.09.2020 18:14, Justin Bertram wro
Would a firewall rule be an option here? It seems like that would be the
best tool to control access to the broker based on IP address. Or is your
use-case more complex than that?
Justin
On Sun, Aug 30, 2020 at 2:19 PM Martin Lichtin
wrote:
> Hi
>
> Looking at how to best implement IP-address
Yes. 5.15.13. It may be an issue with the SSL connector only.
https://issues.apache.org/jira/browse/AMQ-8030
https://issues.apache.org/jira/browse/AMQ-8031
- Martin
On 31.08.2020 06:08, Jean-Baptiste Onofre wrote:
Hi,
I guess you are talking about TCP/OpenWire transport connector.
Which Acti
Hi,
I guess you are talking about TCP/OpenWire transport connector.
Which ActiveMQ version are you talking ?
I remember to have fixed closing of connection in 5.15.13 AFAIR.
Can you please create two Jira (one for the connect hook, one for connection
leaking) ? I will take a look.
Regards
JB
Hi
Looking at how to best implement IP-address based access control via a Plugin.
I've an implementation based on "addConnection", but this method is called way
too late in the connection setup.
Ideally there should be a hook available in TcpConnection.connect() method to
reject rogue connect
