There appears to be a bug where data from the PUBLISH packet is added to
the server-side state before the authz failure and not removed after the
failure. This state still exists when the client reconnects and therefore
the broker ignores the publish thinking it's a duplicate. In reality, it
should only be added once authz succeeds.

Can you open a Jira [1]?


Justin

[1] https://issues.apache.org/jira/browse/ARTEMIS

On Fri, Dec 5, 2025 at 10:41 AM Tommy Tsim <[email protected]> wrote:

> Hi,
>
> We are exploring token-based authentication (i.e., JWT from OAuth)
> with MQTT protocol via custom JAAS LoginModule.
> Tokens will expire at a certain time and LoginModule may cause further
> action (publish QoS2 message) to throw an ActiveMQSecurityException
> (as expected).
> For MQTT 5, the server will respond with Not authorized and leave the
> application to handle.
> For existing applications that are still using MQTT 3.1.1, now artemis
> will disconnect by default [1].
> MQTT client will reconnect (with renewed token) and resend the PUBLISH
> packet.
> However, the session has the PUBLISH packet being marked as
> "received" [2] during the first unauthorized publish.
> When the client reconnects and resends, the server ignores the publish
> and logs "AMQ834009: Ignoring duplicate MQTT QoS2 PUBLISH packet for
> packet ID client from client with ID XX."
>
> The goal is to ensure all QoS2 messages are published eventually. Any
> thoughts?
>
> Thanks.
>
> - Artemis 2.44.0
> - Eclipse Paho MQTT Python client 2.1.0
>
> [1]
> https://activemq.apache.org/components/artemis/documentation/latest/mqtt.html#publish-authorization-failures
> [2]
> https://github.com/apache/activemq-artemis/blob/2.44.0/artemis-protocols/artemis-mqtt-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/mqtt/MQTTPublishManager.java#L209-L212
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>

Reply via email to