oscerd opened a new issue, #1807:
URL: https://github.com/apache/camel-kafka-connector/issues/1807
## Description
This is a design question rather than a defect report, raised so it can be
decided deliberately
rather than by default.
`CamelSinkTask.put()` maps Kafka record headers into the exchange with the
prefix as the only gate
(`CamelSinkTask.java:200-210`, `mapHeader()` at 247-259):
```java
for (Header header : record.headers()) {
if (header.key().startsWith(HEADER_CAMEL_PREFIX)) {
if (mapHeaders) { mapHeader(header, HEADER_CAMEL_PREFIX,
exchange.getMessage().getHeaders()); }
} else if (header.key().startsWith(PROPERTY_CAMEL_PREFIX)) {
if (mapProperties) { mapHeader(header, PROPERTY_CAMEL_PREFIX,
exchange.getProperties()); }
}
}
```
There is no filtering of the post-prefix key, so a `CamelHeader.<X>` record
header becomes exchange
header `<X>` for any `<X>`, including the names Camel components use for
dispatch. The shipped
defaults leave that fully open:
- `camel.map.headers` / `camel.map.properties` default to `true`;
- `camel.remove.headers.pattern` defaults to `""`, so the `ckcRemoveHeader`
template falls back to
its `templateParameter` default `"(?!)"`, which matches nothing.
The Security Model (`docs/modules/ROOT/pages/security-model.adoc`) already
records this under *Known
limitations* — "Header mapping is prefix-gated, not
`HeaderFilterStrategy`-based" — and delegates
stripping to the operator via `camel.remove.headers.pattern`, with the
*Deployment hardening* section
telling operators to set it when the topic has untrusted producers. So the
current behaviour is
documented and intentional; the question the same document leaves open is
whether the **default**
should stay that way.
## Options
1. **Keep as is.** Documented behaviour, operator-controlled, no
compatibility impact.
2. **Ship `camel.remove.headers.pattern` with a default that strips the
Camel-internal namespace**
(e.g. `Camel.*`), so operators opt *in* to passing dispatch headers
through.
3. **Filter in `mapHeader()`** — reject post-prefix keys matching the
Camel-internal namespace unless
an explicit allowlist option names them.
Options 2 and 3 change behaviour for anyone who currently relies on steering
a component through a
mapped header (for example `CamelFileName` on the file/FTP family, which
`docs/modules/ROOT/pages/user-guide/basic-configuration.adoc` documents as a
feature), so either would
need an upgrade note and a release boundary.
Whatever is decided for headers should be decided for
`CamelProperty.`-prefixed properties at the
same time — that channel currently has no strip mechanism at all (see the
`camel.remove.headers.pattern`
ordering issue filed alongside this one).
## Additional Context
Raising this for maintainer/PMC input rather than proposing a patch, since
the Security Model treats
the default as a deliberate, documented choice that "may be tightened over
time through the normal
release and upgrade-note channel".
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
