There are 2 clients (A and B) that are connected to the ActiveMQ Artemis broker. The protocol we are using is MQTT. Both clients have different topic templates that they subscribe. For example client A has subscription topic template of school/readings/# and client B has subscription topic template of Domestic/readings/#.
There will be our server that subscribes all the topics with their respective template.
If client B decides to read all the incoming messages to the broker by subscribing with topic (# or school/#) then there could be a data leak. The requirement here is only our server should subscribe all the topics and other client should have restrictions in topic subscription.
Is there any way to restrict clients subscription or is there any way to avoid this type of data leak?
Both the clients should have the privilege to publish and subscribe to the broker, but one client should not subscribe to another client's topics.
There is no data leak, unless you configured authorization rules and they are not being enforced or you find a way to get unauthorized access when security is enabled (in that case open a bug here). Please, find out here the documentation on how to use security-settings to configure the authorization rules for your use case.
Related
I would like to know if it is possible in a standard MQTT bridge configuration with Mosquitto the dynamic subscription of topics from the MQTT clients to the remote broker.
That is, only if a client requests the subscription to a certain topic, it is Mosquitto who requests to the remote broker the subscription to that topic.
From what I have seen in the configuration it is possible to set it statically when starting the Mosquitto service but not dynamically according to the requirements of the MQTT clients who can decide at runtime to which topics they want to subscribe.
Is it possible in a Mosquitto bridge, a dynamic subscription scenario in which the subscription request of the clients is forwarded to the remote broker?
It is not possible, the broker does not support dynamically changing the bridge subscription.
It's also doing dynamic subscription forwarding won't work well in a situation where usernames/password and ACLs are implemented because the bridge connection acts as any other client connection. This means that the bridge connection can only subscribe/publish to topics allowed by the user assigned to the bridge.
Both brokers are likely to have very different sets of users and ACLs in place
I have multiple devices sending messages to a mosquito broker. I would like to manage a kind of device revocation so that when a device is revoked, I want the mosquito broker to automatically close the connection for this specific device.
Is there any command or way to ask the broker to explicitly close a connection to a specific client?
Thanks in advance,
hak
I do not think you can kick an already connected client.
But what you can do if using the Authentication Plugin (either a 3rd party or the included dynamic security plugin) to change the ACL that the user can publish/subscribe to which should effectively stop the client sending or receiving any messages and when it next tries to connect it will not be allowed.
I wanted to make use of Shared Subscription feature of MQTT v5. But currently I am using AKKA MQTT client which doesn't support MQTT v5 client. Can I still use v3 MQTT paho client and use Shared Subscription feature?
That should not be a problem as from the viewpoint of an MQTT v3 client a shared subscription is just like any subscription.
The broker has to do all the work regarding shared subscription logic.
The only hindrances I can see are:
that an MQTT broker might support v5 but not v3/v3.1.1
the broker doesn't support shared subscriptions in general (yes they exist)
the broker supports all MQTT versions but handles them as two different protocols (not sure if this is a thing)
Using paho client write an app(ensure that this will use MQTT v5) that will have two clients.
Client_v3 will subscribe to the topics from the source i.e. from the app that sends MQTT v3
Client_v5 will publish the received topics as it is received in the above step.
In your application where you want to use shared subscription(again ensure it uses MQTT v5) alter the topics $share/<topic> and make it to get the topics from the client_v5 publish
In simple word: make you paho client code to act as a broker between v3 and v5 apps.
Does Solace support the idea of a client having multiple topic subscriptions that are multiplexed over a single tcp connection?
Yes, you can run multiple topic subscriptions over the same Solace session which connects to one Solace appliance's host and port. Most middleware providers implement this multiplexing however.
MQTT Broker can disconnect the existing client if the following condition is came up.
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc398718090
If the ClientId represents a Client already connected to the Server then the Server MUST disconnect the existing Client
[MQTT-3.1.4-2].
At this time, can broker send any specific message excluding "DISCONNECT" to client before server disconnect the existing client ?
Most brokers are going to follow the spec, if you want one to do something different then you will have to either write your own or modify one of the open source versions.