Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HTTP Proxy to support one format for all Brokers #2

Open
treeder opened this issue Jun 26, 2019 · 2 comments
Open

HTTP Proxy to support one format for all Brokers #2

treeder opened this issue Jun 26, 2019 · 2 comments

Comments

@treeder
Copy link
Owner

treeder commented Jun 26, 2019

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.

@treeder
Copy link
Owner Author

treeder commented Aug 16, 2019

There's probably a lot of progress on this already in the REST endpoint and the websocket endpoint.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants
@treeder and others