Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ADDED] option to keep or remove js headers #5409

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

ramonberrutti
Copy link
Contributor

Add an option to keep or remove headers from a stream.

This is very useful for source streams where sometimes you don't want to store extra headers or have clients you can't control publishing to your streams.

Signed-off-by: Ramon Berrutti [email protected]

@ramonberrutti ramonberrutti requested a review from a team as a code owner May 12, 2024 00:44
@ramonberrutti ramonberrutti changed the title [ADD] option to keep or remove js headers [ADDED] option to keep or remove js headers May 12, 2024
@bruth bruth added the proposal Enhancement idea or proposal label May 12, 2024
@bruth
Copy link
Member

bruth commented May 12, 2024

Hi @ramonberrutti. What concrete use case drove this proposal? You note sourcing. There are messages being sourced that you either want to add or remove headers?

My concern is that this is technically user-defined processing of the message while being replicated. There is still some scoping and designing to do, but there is a plan to introduce a "message callout" which would enable a generic means for single message transforms.

In conversations, the current scope had not considered sourcing/mirroring, but this will be something worth considering.

My concern is that this could be a slippery slope of adding message processing behavior as part of stream configuration.

@ramonberrutti
Copy link
Contributor Author

Hi @ramonberrutti. What concrete use case drove this proposal? You note sourcing. There are messages being sourced that you either want to add or remove headers?

My concern is that this is technically user-defined processing of the message while being replicated. There is still some scoping and designing to do, but there is a plan to introduce a "message callout" which would enable a generic means for single message transforms.

In conversations, the current scope had not considered sourcing/mirroring, but this will be something worth considering.

My concern is that this could be a slippery slope of adding message processing behavior as part of stream configuration.

Hi @bruth

I would love "message callout", but that would be impossible in a high-throughput environment.

There are two big cases that I want to solve right now:

  • Remove: "Nats-Expected-Last-Subject-Sequence" from the KV store without breaking any other flow (I removed the Expected headers from a source stream in a previous PR, already merged)
  • My users have direct access to the KV store (WebSockets), and I want to restrict the headers they can send to the KV or any other subject consumed by the stream.

I agree that this will contain stream logic for message processing.

I'm also updating the PR to support update changes.

@Zetanova
Copy link

Zetanova commented Jul 4, 2024

I have connected users over ws too,
but implemented my own KV because of the lack of list-filters and sub-key permissions

What exact issue can come if a bad client publishes NATS msg-headers?

Should this not be implemented over a permission-map then over a stream properties?

example:

{
            user: test
            permissions: {
                publish: {
                    deny: ">"
                },
                subscribe: {
                    allow: "client.>"
                },
                header_publish: {
                    allow: ["Nats-Msg-Id", "X-*"]
                },
                header_subscribe: {
                    deny: "Nats-*"
                }
            }
}

this would make more sense to let the server filter headers on the client permission for publish and subscribe.

@Zetanova
Copy link

Zetanova commented Jul 4, 2024

I think that I found my aware already.

The header Nats-Rollup: all would negate the client permission on the stream
and purges all messages even if the client has only partial pub permissions to it.

Of course the stream need to be purgeable too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
proposal Enhancement idea or proposal
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants