Doubt about middleware in Mosquitto

[Sergio Guillen]

Hello, I've been testing Mosquitto Broker, I could add plugins for HTTP API auth. But I have a question about subscriptions. For example, User A gets authenticated and gets subscribed to "/sensor/some-sendor-unique-id" and another User B also subscribes to the same topic (in my logic it is valid that user A and B can subscribe to "/sensor/some-sendor-unique-id") but a new User C gets authenticated and also subscribes to "/sensor/some-sendor-unique-id" topic,  but in my logic user C should not be able to subscribe to that topic.

I gave a fast check to Mosquitto's source code, and in file read_handle_server.c there is a "mqtt3_handle_subscribe" method that I could use for making an HTTP request via libcurl, but my point is if there a way I could validate whether a user can subscribe to a given topic or not? maybe is there a middleware in mosquitto or it's just not possible? am I not understanding the MQTT protocol the right way?

Thanks in advance :)

[Roger Light]

Hi Sergio,

This would be better dealt with on the mosquitto-dev mailing list.
Having said that, the issue of denying subscriptions is an important
point for the protocol. It is very difficult to know what to do if
both a subscription ACL and an incoming subscription have wildcards.
If my ACL allowed subscriptions to foo/+/bar, should a subscription to
foo/# be denied?

Generally speaking I think this is better handled at the time of
message delivery. Mosquitto allows subscriptions to be made, but when
a message matches that subscription it checks whether a client is
allowed to receive messages from that topic.

Regards,

Roger

> --
> To learn more about MQTT please visit http://mqtt.org
> ---
> You received this message because you are subscribed to the Google Groups
> "MQTT" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mqtt+uns...@googlegroups.com.
> To post to this group, send email to mq...@googlegroups.com.
> Visit this group at http://groups.google.com/group/mqtt.
> For more options, visit https://groups.google.com/d/optout.

[Laing, Michael]

Actually I think it is better handled at subscription time, and easy enough to check.

So our answer is: foo/# should be denied as it may result in message matches, e.g. foo or foo//, that fail the ACL.

ml

[Karl Palsson]

Well, here's your first dissenter then :)

If I subscribe to foo/# I should be allowed to get any messages that match that, not rejecting my
entire subscription because the acl might have blocked out some subset.

As a subscriber, I might not even know of the existence of some structures that the acl writer
may/may not be working with. Unless you can have an exact, or unambiguous match, I strongly feel
this should be handled on each message.

For instance, I use a system of power/<deviceid>/json/blahlbhalbha trees,
any given device is ACL limited to only write to that +/<deviceid>/# tree, but as a device, I
don't want to, nor should I have to, enter in my device id every time. I can just subscribe to
"#" or "power/#" or whatever, and I get my set of topics. I don't know nor care about others,
that's a broker manager implementation detail, not something a remote subscriber should care
about.

Cheers,
Karl P

[Laing, Michael]

Well perhaps it should be switchable.

In the case you describe the subscriber may have "holes" in the messages received - holes that are enforced by the ACLs - and will never know, possibly believing it got everything in the the subscription pattern.

We prefer to fail the pattern, so that if the pattern succeeds, the subscriber has assurance that every qualifying message will be sent.

For example we might have an ACL of feeds/+/#. A subscription of feeds/breaking-news/+ would succeed but feeds/# should fail, which is what we want.

Michael

[Sergio Guillen]

Hi, all answers were useful for me and yes ACL is the key part I was not considering, 

Thank you :D