Actually you should expect conflicts when cherry-picking to 2.19.0 as there have been significant changes to the MQTT implementation since then (e.g. implementing MQTT 5 in 2.21.0). You might be better off upgrading.
Justin On Fri, Apr 8, 2022 at 1:42 AM Modanese, Riccardo <riccardo.modan...@eurotech.com.invalid> wrote: > Sure, I’ll test asap thanks! > (I’m currently doing my testing on 2.19, I don’t expect conflicts if I > cherry-pick the commit) > > Da: Justin Bertram <jbert...@apache.org> > Data: venerdì, 8 aprile 2022 03:05 > A: users@activemq.apache.org <users@activemq.apache.org> > Oggetto: Re: Artemis security plugin doesn't allow to change clientId > I just sent a PR [1] for this. Riccardo, could you try this out and see if > it works for you? > > > Justin > > [1] https://github.com/apache/activemq-artemis/pull/4021 > > On Thu, Apr 7, 2022 at 2:04 PM Justin Bertram <jbert...@apache.org> wrote: > > > I went ahead and opened ARTEMIS-3770 [1] for this work. > > > > > > Justin > > > > [1] https://issues.apache.org/jira/browse/ARTEMIS-3770 > > > > On Thu, Apr 7, 2022 at 12:35 PM Justin Bertram <jbert...@apache.org> > > wrote: > > > >> Technically speaking, an implementation of > >> o.a.a.a.s.c.s.ActiveMQSecurityManager5 like you have *is* allowed to > change > >> the client ID on the o.a.a.a.s.c.p.RemotingConnection it receives (just > as > >> you are doing in your implementation). The problem is that MQTT > >> implementation doesn't use this client ID and instead overwrites it with > >> the value from the MQTT CONNECT packet. However, I think the code could > be > >> refactored fairly easily to accommodate this use-case. Can you open a > Jira? > >> > >> > >> Justin > >> > >> On Thu, Apr 7, 2022 at 11:19 AM Modanese, Riccardo > >> <riccardo.modan...@eurotech.com.invalid> wrote: > >> > >>> Hello, > >>> we are moving a security plugin from ActiveMQ 5.x broker to Artemis > >>> 2.x. > >>> To summarize the use case: > >>> we need to prefix the MQTT client id provided during the connect > >>> with the account name (something like account_name|client_id) to allow > >>> devices with the same clientId, but different accounts, to connect to > the > >>> broker without triggering the stealing link. > >>> > >>> Doing that with the ActiveMQ was possible. With Artemis SecurityPlugin > >>> any clientId set through the proper RemotingConnection setter has no > effect > >>> ( > >>> > https://github.com/riccardomodanese/kapua/blob/feature-artemisAuthentication/broker/artemis/plugin/src/main/java/org/eclipse/kapua/broker/artemis/plugin/security/SecurityPlugin.java#L140 > >>> ). > >>> Also the fully qualified queue name still use the “original” clientId > >>> without the account_name prefix > >>> > >>> We received a suggestion to use the interceptor but unfortunately the > >>> MQTTConnect is final and has all the fields final so we cannot change > the > >>> clientId > >>> We tried, just as experiment, using reflection to change the > >>> accessibility (no security manager) and it seems to work. But, > obviously, > >>> is just an experiment and cannot be used in a real environment. > >>> > >>> The MQTTConnect message is created by MQTTDecoder ( > >>> > https://github.com/netty/netty/blob/4.1/codec-mqtt/src/main/java/io/netty/handler/codec/mqtt/MqttDecoder.java#L534 > ) > >>> but changing this part to introduce a callback that allows to change > the > >>> decoded clientId is out of the scope of this layer IMHO. > >>> > >>> If someone has suggestion or, better, a solution please tell me! > >>> > >>> Thanks! > >>> > >>> Riccardo Modanese > >>> > >>> >
