Return custom info in user properties of MQTT CONNACK

[Nextdrive-IanChiu]

We intend to provide additional custom information to devices upon connecting to the EMQX broker. Our proposed approach involves adding this information to the user properties section of the MQTT CONNACK packet.

We acknowledge that the HTTP_AUTH_PLUGIN is designed solely to provide an "allow" or "deny" response to the EMQX broker. Are there alternative methods to return custom information to devices following authentication? For instance, could the gRPC Hook be utilized for this purpose?

Environment: EMQX v5

[zmstone]

Hi.
Please consider using the http auth for battle-tested stability and performance.
exhook has not received enough love in the past,
and there is a possibility that we will deprecate exhook in the long run (still an on-going discussion).

[zmstone]

Sorry to whoever came across this message, I misread the original message, thought it was making use of exproto gateway, but typed exhook.
We have done quite some performance improvements for exhook, but exproto is sort of stalled in development work, and we are considering its deprecation.

[zmstone]

Oh, even better than http auth: jwt.

[zmstone]

Sorry I did not read the question carefully.
There is unfortunately no way to insert properties to CONNACK using the current authentication plugins.
You may consider implementing your own plugin to hook into this hookpoint.
https://github.com/emqx/emqx-plugin-template/blob/e7c17ce64d84b54e69973a823e3aca9d417c0e21/src/emqx_plugin_template.erl#L33

[Nextdrive-IanChiu]

Hi @zmstone

Thank you for your prompt response!

Based on the information you provided, I understand that the on_client_connack function can accept props as an argument to modify MQTT v5 user properties. However, I also observed that the on_client_authenticate function only allows passing auth results, and cannot accept props.

In our scenario, assuming that custom information can only be generated during the on_client_authenticate process, would it be necessary for me to store the custom information in a Redis during the on_client_authenticate process and then use the connInfo to map out the custom information during the on_client_connack process before passing it down to the device?

Or do you have a more concise way to suggest for us to use?

[thalesmg]

That's one solution that will make the information available to all nodes in a cluster, assuming they all have access to the Redis server you mention.

Depending on your requirements on how distributed such information must be, if it's not required to be globally accessible, then another option is to use ETS for storing this info. Each node will have its own isolated table, and the information could then be passed from the authn to the connack phase, as the client will still be on the same node. If the client reconnects to another node, though, the previous info won't be available.

[Nextdrive-IanChiu]

Hi @thalesmg
Cool! Since the custom info does not need to be accessed on different nodes, using the ETS solution is the best option to try first. This will help us reduce the number of API calls to just one during the connecting flow.
Thank you for providing the solution!