search

apinf / platform

Apinf - Open source API management platform with multi proxy and protocol support
https://apinf.com/
European Union Public License 1.1
75 stars 35 forks source link

MQTT topic namespacing for EMQ #2842

Open phanimahesh opened 7 years ago

phanimahesh commented 7 years ago

User story

As an MQTT API owner, I expect complete control and flexibility over topics, their structure, and access control rules applied to them, and any other api on the same EMQ must not interfere with mine.

Background:

We intend to support multiple "MQTT APIs" - independent bundles of topics and their access control rules - on the same EMQ instance. A critical requirement to facilitate this is to ensure that conflicts in access control rules do not occur, and to allow only an api owner to set access control rules for the topics they use.

While there are multiple ways to ensure this, the simplest is to assign a namespace to each "api", and to ensure that all topics and relevant acls are constrained to this namespace. This allows an infinite topics for each api while ensuring isolation between apis at topic level.

Definition of done

The intended flow is as follows:

In the proxy tab, if an api selects an emq instance as its "proxy",

If the api does not have an assigned topic prefix:
  1. A text field with label(en) "Topic Prefix" should be displayed. Existing acl and user forms may be visible but must not be enabled for interaction.
  2. The value must be restricted to begin with a /, and must end with a / (or an implicit / may be added at the end when saving). No / may be allowed anywhere else.
  3. Help text or some other suitable indication must be available informing that this can not be changed once set. If possible, a few example topics may be displayed to illustrate. For a prefix of /prefix, each topic entered as /some/topic in ACL form will be interpreted as /prefix/some/topic in MQTT.
  4. Uniqueness must be guaranteed for a topic prefix-emq combination. On the same EMQ instance, a topic prefix once used must be disallowed for any other api. If multiple emq instances are configured, it must be possible to set the same topic prefix for different apis provided they use different emq instances.
  5. On saving, the topic prefix must be remembered for the api, and should display the value prominently. ACL and user forms must be available for interaction.
If the api has an assigned topic prefix:
  1. The topic prefix must be displayed before the topic field in ACL form, visually indicating that this is the fixed, non editable part of topic.
  2. On saving access control rules, EMQ database must be updated with these, after prepending the prefix to every topic.

Additional explanation

This is the simplest solution I can think of after going down more than a few false starts and dead ends.

Modifying topic prefixes is disallowed since reliably updating emq side of the ACLs is a pain. It would be simpler to change emq ACL schema and related query logic than blindly updating all rules. This will be handled in a future issue.

I am fully aware that topics are not restricted to start with / in MQTT specification. However, for simplicity, we will require this. It also leaves open an option to namespace an organisation, allowing organisation/api-prefix as possible prefix structure in future. Every MQTT client works well with topics starting with /, I haven't tested as many with arbitrary initial characters. Brokers reserve some namespaces, typically beginning with $, such as the $SYS/# subtree. Requiring / sidesteps the possibility of present and future conflicts, even if the chance is minimal.

amardeep-deligence commented 7 years ago

Proceeded with this information and did some research but requirement is still not clear, may be because of lack of domain knowledge. So, please clarify more.

phanimahesh commented 7 years ago

That is a bit vague and doesn't give me much to work with. Can you point out specific points that need more explanation, or describe your doubts or questions in detail?

If not, we'll discuss this over our scheduled call.

On Sat 2 Sep, 2017, 17:58 amardeep-deligence notifications@github.com wrote:

Proceeded with this information and did some research but requirement is still not clear, may be because of lack of domain knowledge. So, please clarify more.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/apinf/platform/issues/2842#issuecomment-326741309, or mute the thread https://github.com/notifications/unsubscribe-auth/ABnL8J-YNIWUWrmhAIWvniQyIH3Tizc-ks5seUoDgaJpZM4O_gbq .

preriasusi commented 6 years ago

@saransh-dev Could you answer to @phanimahesh, and let us know if you won't work with this.

saransh-dev commented 6 years ago

Hi @preriasusi, @amardeep-deligence has worked on this issue and created PR of it and commented for review.

amardeep-deligence commented on Sep 28 @bajiat @phanimahesh @marla-singer @brylie this PR is ready for review.

Nazarah commented 5 years ago

Relates to #2657