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.
Related
Does the Paho Java client has any callback function called when a new client connection is established? Within that function I want to validate user and if failed refuse connection.
When a new client connect from javascript or any client I should be able to allow or refuse new client.
This is not possible to do from a client, the MQTT protocol has no support for anything other than passing authentication information from a single client to the broker, not the other way round.
You have to do it from within the broker. Different brokers all implement authentication differently so it will depend entirely on which broker you are using.
Mosquitto has an API to write authentication plugins. e.g. https://github.com/jpmens/mosquitto-auth-plug
HiveMQ Also has an API http://www.hivemq.com/blog/mqtt-security-fundamentals-advanced-authentication-mechanisms
Mosca - https://github.com/mcollina/mosca/wiki/Authentication-&-Authorization
I noticed that when an MQTT Client with the same Client ID as another MQTT Client already connected to Solace, the second client will get "Not authorized to connect (5)" error message. When I tried the same scenario but connect to a different Solace appliance, the second client succeeded in connecting but the first client was disconnected forcefully by Solace. I checked the settings in both appliances but could not find any settings that lead to the different behaviour. Can anyone advise?
When a new client connects to a Solace appliance, and that client uses the same client name as an existing, connected client, you can configure the appliance to either:
reject the new duplicate client’s connection attempt
disconnect the existing client and connect the new, duplicate client
By default, the replacement of duplicate client connections during authentication is enabled on the appliance. To disable the replacement of duplicate client connections during authentication, use the following CONFIG command:
solace(config)# authentication
solace(config-auth)# no replace-duplicate-client-connections
If you are using SolAdmin to manage the appliance, you can change this property by navigating to the User Management tab, and selecting User Authentication from the Select View box. From the box at the right side of the Element Details area, select Manage Global Authentication, and click Execute Task. In the dialog box that appears, you can select or clear the Replace Duplicate Client Connections check box.
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.
Currently I need to implement socks client. According RFC, Socks protocol has two main commands: CONNECT and BIND. CONNECT is used to forward an outbound connection from socks' client to desired Server. BIND is used to forward an inbound connection from desired Server to socks' client.
My client work as follows:
Firstly It makes connection to socks Server, let us call it a "client connection".
After that it issues commands.
I have some misunderstanding with a "client connection" utilisation. Hence, I have the following questions:
A "client connection" could be used only for one CONNECTION command, is that right ? So for each desired communication I need to create a new "client connection" and after that issue command CONNECT.
For BINDing, firstly, i need to issue CONNECT and after issue command BIND. These commands must be issued in a one "client connection", am I right ?
How many inbound connections socks server could receive on BIND socket ? Only one ?
How traffic flows in case of BIND is used ? We have a "client connection" to socks server. For the "client connection" socks server has one connection to desired server and one incoming connection from desired server. Hence, socks server could receive data from two connections. How this traffic is mixed to the "client connection"?
Yes.
No. BIND is separate from CONNECT. It is for when you want to listen, so you tell the server to listen on your behalf and tell him what port you're listening on.
Pass.
There is only one connection between the client and the SOCKS server. Everything arriving from the client is sent to the 'desired server'. Everything arriving from the 'desired server' is sent to the client. There is nothing to mix. You wouldn't want the client's sends to be sent back to him, would you?
I have installed Ejabberd in our AWS Server
We are developing an iOS messenger app and we don't want other clients to access our messaging server other than our iOS app.
All the ejabberd services should be accessible only by our iOS app,
To register
To login
To send message and use any other service.
What are all the configurations and settings should I have to do to secure our server?
There is no 100% way to disable other clients from mimicking your own client. You may use different protocol, or one more layer of encryption or special marks that allow your server use to make sure that client is yours. But if someone will have desire to write his own client, he'll use your own client to understand what should be sent on the wire.
XMPP is build on the top of TCP so there is no good way of restricting access to the server socket. If you want to be compliant with XMPP you need to use encryption, otherwise use your own custom protocol (like Skype).