You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Let me know if this is not the right place to post this feature request. I'm posting this request based on this discussion: emqx/emqx#11528
Basically, with the introduction of User Properties in the V5 version of the MQTT protocol, I think it expands the possibility to enhance authentication processes by allowing the specified properties to be used as placeholders in different authentication/authorization services.
for my particular use-case, I want do to something like this:
A client sets a User-Property of (ApiKey, ABC123) in the CONNECT packet along with a username and a password.
EMQx sees this and sends as a POST request a username, password and ApiKey: ABC123 to an external HTTP service.
The HTTP Service receives a JSON object like this: {"username": ..., "password": ..., "apiKey": "ABC123" }.
Or expose them via headers too, so the HTTP Endpoint receives a custom header like X-API-KEY: ABC123.
Also, allowing user properties to be used as placeholders, will allow more granular control over the PUBLISH packet as well with ACLs.
Thanks!
The text was updated successfully, but these errors were encountered:
Hola! 👋
Let me know if this is not the right place to post this feature request. I'm posting this request based on this discussion: emqx/emqx#11528
Basically, with the introduction of User Properties in the V5 version of the MQTT protocol, I think it expands the possibility to enhance authentication processes by allowing the specified properties to be used as placeholders in different authentication/authorization services.
for my particular use-case, I want do to something like this:
(ApiKey, ABC123)
in theCONNECT
packet along with ausername
and apassword
.username
,password
andApiKey: ABC123
to an external HTTP service.{"username": ..., "password": ..., "apiKey": "ABC123" }
.Or expose them via headers too, so the HTTP Endpoint receives a custom header like
X-API-KEY: ABC123
.Also, allowing user properties to be used as placeholders, will allow more granular control over the
PUBLISH
packet as well with ACLs.Thanks!
The text was updated successfully, but these errors were encountered: