1

I made an instant messaging app using MQTT protocol. I want to add some extra data about messages in payload like sent time ( server time not client time ) and also provide kind of server side payload sanitizing.

Is it a good idea to add a third party client with superuser privileges between message sender and message receiver on broker's local machine to do this job ? or is there any better idea ?

by the way I'm using EMQTT as message broker.

Masoud Aghaei
  • 1,113
  • 2
  • 15
  • 27
  • The only way a 3rd party client could do what you ask would be if it changed the topic as it it worked on the message. What you want is a broker with server side hooks like mosca. I'm not familiar with EMQTT to know if it has this capability – hardillb Nov 09 '16 at 12:24

1 Answers1

2

From a pure security view having direct peer to peer traffic (without filtering and sanitising) sounds like a dangerous idea. (At least in the Internet-of-things domain I would clearly object against it.)

Why? Because the clients are outside of your control (i.e. a hacker can re-engineer) and inject any traffic to exploit security holes on the receiving side of other clients.

So sanitising on the server side sounds like a very good idea.

I would suggest two topics: One (inbound) topic the clients use to publish messages, and another (outbound) topic used by clients to subscribe to messages. A server side component would then read the messages from inbound topic, sanitize it and publish to the outbound topic.

This de-coupeling makes it also easier to introduce MQTT payload changed: If you update the payload in a non-compatible way, introduce a new inbound topic and keep the old inbound topic too. This allows you to support old and new clients during the transition phase.

Stefan Vaillant
  • 511
  • 3
  • 6
  • tanks for your answer. I think like this , but what about performance and high availability issue ? and how do you compare this mechanism with using or creating broker plugins ? – Masoud Aghaei Nov 10 '16 at 13:51
  • Broker plugins: Sounds fine, but we do not have experience with that. High availability: If you e.g. deploy the "service side component" to the same server, I do not see much additional complexity. Performance: Yes, some degration, but IMHO not critical. If the broker plugin runs in-process, it might be preferred solution IMHO. – Stefan Vaillant Nov 11 '16 at 13:36