[
https://issues.apache.org/jira/browse/ARTEMIS-592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15422542#comment-15422542
]
Martyn Taylor commented on ARTEMIS-592:
---------------------------------------
"Can we send messages directly to these queues? With Apollo and ActiveMQ 5.x,
we can."
In STOMP this is possible. But not just any client has access to the queue.
The STOMP implementation will prepend durable subscriptions with the client-id.
So subscribing to "foo" with client-id "123" allows you to consume from the
queue "123.foo". This is how the STOMP implementation behaves.
"Do we allow multiple connections to the same queue (see @clebertsuconic
question "Wouldn't be easier if we just failed more than one connection with
the same client-id?")? With Apollo and ActiveMQ 5.x, we can and messages will
be split between all consumers, like with regular queues."
We do. Similar to how we handle durable subscriptions (explained above). It's
possible to have more than 1 STOMP client with the same ID connect to the
broker. Thus, all clients with ID 123 are able to subscribe to "123.foo".
This has some limitations, a client with ID 123, is not able to "share a
durable subscription queue" with client ID 456. This behaviour of sharing
queues based on the client-id field isn't supported across all protocols. In
order to do this we may have to break the spec of some protocols (which may or
may not be acceptable) MQTT is an example of where this is explicitly outlined
in the spec as not supported.
TBH I'm not sure if the shared durable subscription ability (through client-id)
was intentional or was a side effect of the implementation.
"Can we define different security settings (this is the initial scope of this
Jira issue)? With Apollo and ActiveMQ 5.x, we can."
Yes this fix allows you to do that with STOMP.
"Since Artemis supports multiple protocols, the next question is how much of
this is (mostly) protocol independent and ends up in the Core and how much is
protocol specific."
Justin's point, which I think is a good one. Is that by securing queues, it's
possible to apply it across protocols. The slight concern I had was that
protocol implementations use queues to expose the desired protocol features.
Using security settings at the queue level, requires exposing the underlying
implementation details of each protocol. I'm now feeling OK with this if we
can somehow standardise the internal naming schemes across all protocols. I
believe STOMP durable subscriptions are <client-d>.<subscription-id>, MQTT is
similar <client-id>.<subscription-address>.
"From a user point of view, the more gets protocol independent, the better. I
would prefer to have the same security settings regarding which protocols the
clients end up using. Justin's proposal to concatenate the address and queue
names looks fine to me."
Yes, to make this non protocol specific we could perhaps support something
similar to virtual destinations or standardise on the naming scheme.
> Allow fine grain access control (durable subscriptions)
> -------------------------------------------------------
>
> Key: ARTEMIS-592
> URL: https://issues.apache.org/jira/browse/ARTEMIS-592
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Reporter: Lionel Cons
> Assignee: Justin Bertram
>
> According to the documentation:
> {quote}
> Apache ActiveMQ Artemis allows sets of permissions to be defined against the
> queues based on their address.
> {quote}
> Two different subscriptions on the same topic will have the same address (the
> topic), only their name will change. So it seems they will get the same
> permissions.
> Could you please allow fine grain access control to be able to set different
> permissions to different durable subscriptions of the same topic?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
