-
Notifications
You must be signed in to change notification settings - Fork 67
Investigate if client ID can be safely propagated to authn backends #139
Comments
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 Unfortunately, the most obvious location to pass in the client ID would be in |
@acogoluegnes what if we detect what protocol is used in |
@michaelklishin Looks good to me, thanks. Stable or master? |
@acogoluegnes master only sounds reasonable to me. |
I should clarify the function in e.g. |
Those extra arguments are extracted from an external module, the convention being "rabbit_%protocol%_connection_info" for the module name. This allows to pass in plugin-specific authentication arguments, e.g. client ID in the case of MQTT. Part of rabbitmq/rabbitmq-mqtt#139
Requests to my auth backend server's
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( |
@rasgele please use the mailing list for discussions and provide a way to reproduce. This is not something that's commonly reported. |
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.
The text was updated successfully, but these errors were encountered: