[
https://issues.apache.org/jira/browse/CAMEL-24370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18106667#comment-18106667
]
Andrea Cosentino commented on CAMEL-24370:
------------------------------------------
Implementation note after investigation:
* Part 1 (resolve the filter via DeserializationFilterHelper in ObjectDecoder)
is done - the 1-arg / null path now falls back to the JVM jdk.serialFilter and
then the shared Camel default allow-list instead of applying no filter.
DatagramPacketObjectDecoder inherits this by delegation.
* Part 2 (a deserializationFilter endpoint option threaded to the codecs)
turned out not to be applicable: unlike camel-netty-http, plain camel-netty
never auto-instantiates the object codecs - ObjectEncoder/ObjectDecoder are
always user-supplied via the encoders/decoders bean refs (there is no
component-built codec to thread an endpoint option into, not even for
transferExchange). The configuration surface is therefore the existing
two-argument ObjectDecoder(ClassResolver, String) /
DatagramPacketObjectDecoder(ClassResolver, String) constructor, which is
documented in netty-component.adoc. No endpoint option was added (it would have
been a dead no-op).
* Docs + upgrade-guide note added; the pre-fix reproducer test was replaced by
ObjectDecoderDeserializationFilterTest (EmbeddedChannel) which verifies
rejection of a non-allow-listed class, allow-listed pass-through, and
explicit-filter override.
> camel-netty - resolve the shared deserialization filter in the object codecs
> and expose deserializationFilter on the endpoint
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-24370
> URL: https://issues.apache.org/jira/browse/CAMEL-24370
> Project: Camel
> Issue Type: Improvement
> Components: camel-netty
> Reporter: Andrea Cosentino
> Assignee: Andrea Cosentino
> Priority: Major
> Fix For: 4.23.0
>
>
> h3. Background
> The camel-netty object codecs are the last Java-serialization entry points in
> the component tree that do not resolve their {{ObjectInputFilter}} through
> the shared {{DeserializationFilterHelper}} introduced in CAMEL-23815.
> h3. Current state
> * {{org.apache.camel.component.netty.codec.ObjectDecoder}} sets an
> {{ObjectInputFilter}} only when the {{deserializationFilter}} constructor
> argument is non-null. The single-argument constructor passes {{null}}, so
> decoders built that way apply no filter at all and only emit a WARN log.
> * {{org.apache.camel.component.netty.codec.DatagramPacketObjectDecoder}}
> inherits the same behaviour by delegation.
> * Within the same component, {{NettyConverter}} already calls
> {{DeserializationFilterHelper.resolveDeserializationFilter(null)}}, so the
> type-converter path and the codec path behave inconsistently.
> * The netty endpoint exposes no {{deserializationFilter}} option, while
> camel-netty-http and twelve other components do.
> h3. Proposed change
> # Resolve the filter in {{ObjectDecoder}} through
> {{DeserializationFilterHelper.resolveDeserializationFilter(...)}}, so that an
> unset pattern falls back to the JVM-wide {{jdk.serialFilter}} and then to the
> shared Camel default instead of applying no filter.
> # Add a {{deserializationFilter}} option on the netty component and endpoint
> for parity with camel-netty-http, and thread it through to the codecs.
> # Document the option and the recommended setting for routes that use the
> {{ObjectEncoder}} / {{ObjectDecoder}} pair in {{netty-component.adoc}}.
> h3. Compatibility
> This is a behaviour change for existing routes that wire {{ObjectDecoder}}
> explicitly: classes outside the default allow-list will start to be rejected.
> It needs an entry in
> {{docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_23.adoc}}.
> h3. Related
> CAMEL-23297 added the {{deserializationFilter}} argument to these codecs,
> CAMEL-23815 introduced the shared helper, and CAMEL-24296 applied the same
> default to {{CamelObjectInputStream}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
