Investigate if client ID can be safely propagated to authn backends

[Michael Klishin]

See #137 for the idea. This makes sense for some authn backends (e.g. HTTP, possibly LDAP) but not others (e.g. internal database backend won't use the client ID value).

rabbit_authn_backend: user_login_authentication/2 already accepts additional options.

@acogoluegnes may have additional thoughts.

[Arnaud Cogoluègnes]

The authentication backends usually extract the credentials from a list of tuples (e.g. in the internal backend). So it should be safe to add an extra client_id tuple.

Unfortunately, the most obvious location to pass in the client ID would be in rabbit_direct (so not just in the MQTT plugin), where the connection info is available (with the MQTT client ID inside it). We could change this call.

[Michael Klishin]

@acogoluegnes what if we detect what protocol is used in connect/5 and come up with a convention that retrieves additional arguments from a module in that plugin, e.g. rabbit_mqtt_connection_info, rabbit_stomp_connection_info, etc. This way rabbit_direct would have next to no protocol-specific bits. Connection info modules can return a proplist/map that is merged with the credentials we already pass on.

[Arnaud Cogoluègnes]

@michaelklishin Looks good to me, thanks. Stable or master?

[Michael Klishin]

@acogoluegnes master only sounds reasonable to me.

[Michael Klishin]

I should clarify the function in e.g. rabbit_mqtt_connection_info, say, rabbit_mqtt_connection_info:additional_authn_params/N, will accept some or all of the same arguments as connect/5. Providing more context sounds like the right thing to do here.

[volkan]

Requests to my auth backend server's auth/user has this body:
{username: "guest", password: "guest", vhost: "/"}
Although in /auth/topic I receive such body,

{ 
  username: 'guest',
  vhost: '/',
  resource: 'topic',
  name: 'amq.topic',
  permission: 'write',
  routing_key: 'mytenant.agent-00000000.inbox',
  'variable_map.client_id': 'publisherclient-randomid-0',
  'variable_map.username': 'guest',
  'variable_map.vhost': '/' 
}

So it seems extra props(e.g. client_id) is not passed for auth/user endpoint, which is the point of #137 Am I missing smth?

P.S. I run 3.7.6 version( {rabbit,"RabbitMQ","3.7.6"})

[Michael Klishin]

@rasgele please use the mailing list for discussions and provide a way to reproduce. This is not something that's commonly reported.