Hi,
we’re working with Event-Store 4.1.1-hotfix1 and are facing a problem related to ACLs.
It seems that any user can connect to and successfully receive events from any already existent persistent subscription, regardless of the ACL on the underlying streams.
Curiously enough we couldn’t observe this behavior with catch-up-subscriptions, there were no exceptions but unauthorized users simply don’t receive any messages, which if fine.
Why don’t persistent subscriptions behave the same way?
This is not as simple as you might think let me put forward an example. You have prefer-round-robin setup but not all clients in the group have permissions to read all streams the group may receive. This is why the feature got put on the backburner.
Another example might be consumer 1 says it can’t handle the message (versioning can cause this) so move it to consumer 2 except consumer 2 does not have appropriate privileges.
There are two obvious solutions here:
actually run permission checks on every message when trying to select a consumer (this actually has some really ugly edge cases ^^^)
only allow consumers with the same privs into the consuming group
I am guessing #2 is the more likely of the two to be implemented. What are your thoughts?
Solution #2 would be totally sufficient for our use case.
I fail to understand why ACL is on low priority considering it’s pretty critical for business users and this is quite a significant security hole, potentially any user could read any events.
This is just another missing-feature/bug in this sphere that forces us to workarounds.
ACLs already exist in general I was referring to ACLs for $all subscriptions where it supports multiple consumers of different privilege levels and dispatching accordingly. Sorry if I was not clear.
I know that ACL exists in general. I was just venting my frustrations about trying to use it.
In my humble opinion what I described here is not so much a missing feature but a serious bug considering it renders ACL read-permissions pretty much useless.
I am mostly trying to figure out what exactly you want to work.
Personally I would rather be able to control access to the subscription group than to the underlying stream(s). This is actually quite easy to do and could be done and in the next release (guessing, need to look at schedule). If done at a stream level what happens when you have multiple subscribers with differing security profiles in the same subscriber group? This can get weird pretty quickly as subscriber 1 may not have permissions to see this message while subscriber 2 does, subscriber 2 currently has a full buffer though…
Controlling access to the subscription group is fine and I’d be happy with that.
I’m relieved to here that it’s an easy fix and on your schedule.
thank you for taking the complaint seriously.