oscerd opened a new pull request, #25587: URL: https://github.com/apache/camel/pull/25587
## Description `RedisConfiguration.createDefaultSerializer()` builds a bare `JdkSerializationRedisSerializer`, whose read path runs through Spring's `ConfigurableObjectInputStream` with **no `ObjectInputFilter` installed**. Every other component in the codebase that performs JDK deserialization resolves a filter first — `camel-consul`, `camel-leveldb`, `camel-mina`, `camel-netty`, `camel-netty-http`, `camel-vertx-http`, `camel-jms`, `camel-sjms`, `camel-http-common`, `camel-cassandraql`. `camel-spring-redis` was the one path left without one. It was missed by earlier passes because it never constructs an `ObjectInputStream` itself — it delegates to a Spring class, so it is invisible to a search for `new ObjectInputStream(`. ## Changes Adds a `deserializationFilter` endpoint option (`advanced,security`). The default serializer now installs a filter resolved through `DeserializationFilterHelper`: the configured pattern when set, otherwise the JVM-wide `jdk.serialFilter`, otherwise the shared Camel allow-list. `JdkSerializationRedisSerializer` exposes no hook for a filter, so the serializer is built through its `Converter`-based constructor with a deserializing converter (`FilteringDeserializer`) that sets one on the stream. Serialization is untouched, and class resolution is unchanged — the same `null` class loader Spring's `DefaultDeserializer` uses by default is passed through. This covers the three places sharing the default serializer: | Path | Reached via | |---|---| | Consumer | `RedisConsumer.setBody()` → `getSerializer()` | | Producer read commands (`GET`, `HGET`, `HGETALL`, `HVALS`, …) | `createDefaultTemplate()` → `getSerializer()` | | `SpringRedisIdempotentRepository` | builds that same template | Worth noting: setting a custom `redisTemplate` does **not** reach the consumer, which reads `getSerializer()` directly rather than the template's serializer. The new option covers both paths. Setting the `serializer` option to a custom `RedisSerializer` bypasses the filter, since Camel then no longer controls how the payload is read. ## Testing 5 new tests in `RedisConfigurationDeserializationFilterTest` — allowed-type round trip, rejection of a denied `java.net.*` type, rejection of a type outside the allow-list, a configured filter overriding the default, and confirmation that a custom `serializer` is left alone. - `123/123` module tests pass, no regressions - Full reactor build green (696 modules), generated metadata in sync - `assertj-core` added test-scoped; managed in parent and already declared by sibling `camel-spring-parent` modules ## Documentation Upgrade-guide entry in `camel-4x-upgrade-guide-4_23.adoc` — this changes a default, so routes exchanging classes outside the allow-list need to widen it via the new option. ## Backports Applies to `camel-4.22.x`, `camel-4.18.x` and `camel-4.14.x` as well. On 4.18.x and 4.14.x `DeserializationFilterHelper` does not exist, so those will follow the local-constant pattern already used there by `NettyHttpHelper` / `JmsBinding` / `MinaConverter`. --- _Claude Code on behalf of oscerd_ -- 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]
