Change authorization errors to be error-silent

[dmoranj]

Current behavior of the plugin is to raise an error each time a user makes an unathorized action, so informing the user explicitly that an error has a occurred. This behavior does not match other MQTT broker behaviors, where no information is given to the user about its available permissions, so the error remains silent:

• if the user publish an unathorized message, the message is silently dropped.
• if the user connects to an authorized queue, no messages are never redirected to its client.

Since the leit motiv of this plugin is to mimic the desired MQTT broker behavior in RabbitMQ, it should change the way it manages the errors. This behavior could be implemented by rewriting the destination topic for both publish and queue bind messages, moving them to a trash/+ topic (taking care that no two unauthorized queues end up in the same trash queue). This approach has the additional advantage of eliminating the reconnection problem that currently happens with some MQTT clients (as the command line Mosquitto MQTT subscriber): if a client is not authorized and its connection is closed, it tries to reconnect forever, thus wasting the broker's resources. If the silent error policy is implemented, the client will make a single silent unused connection.

[rfgtid]

I assume that you are referring to a client properly autheticated but not authorized.

The problem I see is that MQTT standard clearly states about the authentication

If a server sends a CONNACK packet containing a non-zero return code it MUST then close the Network Connection [MQTT-3.2.2-5].

but I think it leaves out authorization proble up to the upper layer.

I am on the of "fail soon, fail often" camp. If the MQTT client is not aware that its messages are being silentry discarded, it won't be easy/fast to diagnose. It could be arguied that it is up to the using application to articulate such mechanisms like a well known topic for errors, but it requires more boilerplate.

[fgalan]

Looking to how other protocols work (in particular HTTP), when the user tries to access to unauthorized resources it gets a 403 Forbbiden, not a silent ignore (200 OK could be the HTTP equivalente to silent ignoring in this case).

However, HTTP is far away from MQTT or AMQT from a protocol point of view, so not sure if the above piece of feedback is meaniful in this context (in other words, feel free to ignore it :)

[dmoranj]

In discussion with @mrutid we decided to implement the silent failure mechanism, offering some way to the users to access the trashed messages (publishing the trash queues, and protecting them using standard RabbitMQ mechanisms). The main reason to do so is to mimick the current MQTT broker's behavior, in order to ease the transition from the current mosquitto-based environments to the new RabbitMQ-based ones.

[rfgtid]

Regarding the Trash queue. I think it is important to enforce a hard limit to avoid an unbounded growth After passing this high watermark all messages should be silently discarded to "/dev/null"