mqtt client_id support

[kbudde]

According to the documentation https://www.rabbitmq.com/access-control.html#topic-authorisation the client_id can be used in topic authorisation.

Is the client_id currently provided to the web server?
If not I think it makes sense to add this information to at least user_path and topic_path requests.

Internal (default) authorisation backend supports variable expansion in permission patterns. Three variables are supported: username, vhost, and client_id. Note that client_id only applies to MQTT. For example, if tonyg is the connected user, the permission ^{username}-.* is expanded to ^tonyg-.*

[michaelklishin]

There's already an issue for that rabbitmq/rabbitmq-mqtt#152.

[michaelklishin]

No, that's not really a duplicate but this plugin doesn't control what kind of context it gets, so I'll file a separate one in the MQTT plugin.

[acogoluegnes]

@kbudde Have you tried actually? Because client_id should be propagated to the HTTP backend, at least for topic authorization.

The MQTT plugin adds the client_id to the context for topic authorization: https://github.com/rabbitmq/rabbitmq-mqtt/blob/d92fa2aed107147e4bab1ae8cc0dc5dddfcc4b75/src/rabbit_mqtt_processor.erl#L855-L863

The HTTP backend plugin propagates it to the actual backend:

rabbitmq-auth-backend-http/src/rabbit_auth_backend_http.erl

Lines 75 to 84 in 96d6635

	check_topic_access(#auth_user{username = Username},
	#resource{virtual_host = VHost, kind = topic = Type, name = Name},
	Permission,
	Context) ->
	OptionsParameters = context_as_parameters(Context),
	bool_req(topic_path, [{username, Username},
	{vhost, VHost},
	{resource, Type},
	{name, Name},
	{permission, Permission}] ++ OptionsParameters).

[kbudde]

Hi,

the client_id is there for topic authorization.
It is as well included in the header of the user request with a different name (var_map..)