How will multifilter consumer reflect on API?

[tpihl]

I'm looking at the jetstream wire API, more specifically:
$JS.API.CONSUMER.CREATE...

I agree 100% that this (new-ish) alternative released in v2.9.0, but it looks like multifilter consumer will use the old API and not support permission-check.

Is there an not-yet-implemented future way to enforce permission-check for the old interface? If there is a future solution, is there a time-frame?

/T

[derekcollison]

We realize we do not have a good permission scheme yet for multi-subject consumers. Working on it.

[tpihl]

Thank you.

How about a slightly more abstract one @derekcollison?

You may create a consumer if you have permissions to do a normal nats subscribe on the same subjects. If you're allowed to listen to the data when it's published to the stream, you're also allowed to consume it after the fact.

It would fit the publish permission that could also control that you're only allowed to create streams that capture subjects that you're allowed to publish to

The implementation would not be on the wire API, but a check done server-side when payload is received/parsed.

Would that work? Could be same for buckets and any of our parts, use the core nats permission model. subject-rewrite could be part to add more options (not sure if it would be before or after though)

/T

[derekcollison]

Was thinking about that a bit. I think we would need to answer the question of how would a user restrict access to one but not the other? E.g. NATS core subs should not be allowed, only jetstream subs.

[tpihl]

Agreed. Could that be solved with something similar to AllowReply, like JetStreamDenyEavesdrop :)

I'm however not sure of if that is really valuable unless there is a valid usecase where you may eavesdrop live but not consume after the fact. Anyone really needing that usecase also have the RePublish on another subject where the eavesdropper are allowed. The use-case that we only may read history but not current seems unlikely since any consumer will end up showing current when older msgs are processed.

My perspective is mostly that since we don't allow more than one stream to capture any single subject, the stream is somewhat exclusive and I'd be ok that the same restriction is applied on normal users.
I don't know if an overlapping core subscriber can reply to a msg where the publisher(requestor) expect a reply from the stream. It should not be allowed in my opinion. And that would actually both usecases (core and jetstream stream) mutaly exclusive in using the actual subscribe permission (limiting core subscribe to not allow overlapping jetstream subjects). The separation/removal subscribe to be core only and consumer to be jetstream only, the definitions would feel reasonable.

another way for that separation would be to add a component (consume) in permissions to make it three core parts (subscribe - only for core nats, consume - only to define subjects you may include in the created consumer, and publish - as is today)

Or am I missing something @derekcollison ?

/T