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
One way to deal with authentication and security is to keep it like it is generally done now with a REST API in front of it. This way, it can still utilize common security practices like token based authentication and HTTPS security. Most brokers are not built with public facing APIs in mind, so they don't handle this very well and are all quite different in how they handle it (eg: MQTT supports plain text username/password or you could get more technical and use X.509 certificates on the TLS handshake, but are you really going to make your users remember an X.509 cert?).
Additionally, most of these brokers don't have good browser client support. Nats requires a websockets to tcp proxy/relay anyways. Only one MQTT broker, HiveMQ, that I could find has a browser capable client.
Solution
We could define a common input and output wrapper format for all events along these lines:
Why?
Authentication / Security
One way to deal with authentication and security is to keep it like it is generally done now with a REST API in front of it. This way, it can still utilize common security practices like token based authentication and HTTPS security. Most brokers are not built with public facing APIs in mind, so they don't handle this very well and are all quite different in how they handle it (eg: MQTT supports plain text username/password or you could get more technical and use X.509 certificates on the TLS handshake, but are you really going to make your users remember an X.509 cert?).
AsyncAPI has some things in the spec, but seems mostly http related:
https://www.asyncapi.com/docs/specifications/2.0.0-rc1/#securitySchemeObject
Browser support
Additionally, most of these brokers don't have good browser client support. Nats requires a websockets to tcp proxy/relay anyways. Only one MQTT broker, HiveMQ, that I could find has a browser capable client.
Solution
We could define a common input and output wrapper format for all events along these lines:
AsyncAPI servers.protocol: "rest?"
To publish:
POST /event_endpoint
Authorization: Bearer ABC
{
"channel": "abc",
"message/payload": [ASYNCAPI SPEC
message
],}
To subscribe via websockets:
GET wss://{servers.URL} HTTP/1.1
Origin: http://example.com
Authorization: Bearer ABC
Connection: Upgrade
Host: {servers.URL}
Upgrade: websocket
First message sent to subscribe:
{
"command": "subscribe",
"channel": "abc",
}
Then receives all messages on "abc" channel. This could be a direct proxy to the underlying broker, very thin.
Could have similar websocket scheme for publishing too.
The text was updated successfully, but these errors were encountered: