[
https://issues.apache.org/jira/browse/CASSSIDECAR-504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bohdan Siryk updated CASSSIDECAR-504:
-------------------------------------
Description:
Spotted during review of CASSSIDECAR-501.
Basically, *RestoreJobConfigurationImpl* is validated only through its builder,
while Jackson takes another path to instantiate and parse values into config
object which results in bypassing validation.
Across the codebase, validation of each config setting is delegated to its
setters. It's enough for single setting validation, but it's not possible for
settings that depend on other settings like _jobDiscoveryMinimumRecencyDays_ of
{*}RestoreJobConfigurationImpl{*}. Value _jobDiscoveryMinimumRecencyDays_
cannot be greater than
_restoreJobTablesTtl_ value which is configurable. The order of deseriazliation
is unknown, so we have to validate object right after it is deserialized
(including calls of setters).
We can achieve such by hooking into Jackson deserialize chain (using
{*}BeanDeserializerModifier{*}) and validate object there or just by creating
an all arg constructor with @JsonCreator annotation so removing all setters
entirely.
I tried to implement the first approach with help of AI
[here|https://github.com/apache/cassandra-sidecar/compare/trunk...worryg0d:cassandra-sidecar:jackson-validating-deserializer?expand=1]
was:
Spotted during review of CASSSIDECAR-501.
Basically, *RestoreJobConfigurationImpl* is validated only through its builder,
while Jackson takes another path to instantiate and parse values into config
object which results in bypassing validation.
Across the codebase, validation of each config setting is delegated to its
setters. It's enough for single setting validation, but it's not possible for
settings that depend on other settings like _jobDiscoveryMinimumRecencyDays_ of
{*}RestoreJobConfigurationImpl{*}. Value _jobDiscoveryMinimumRecencyDays_
cannot be greater than
_restoreJobTablesTtl_ value which is configurable. The order of deseriazliation
is unknown, so we have to validate object right after it is deserialized
(including calls of setters).
We can achieve such by hooking into Jackson deserialize chain (using
{*}BeanDeserializerModifier{*}) and validate object there or just by creating
an all arg constructor with @JsonCreator annotation so removing all setters
entirely.
I tried to implement the first approach help of AI
[here|https://github.com/apache/cassandra-sidecar/compare/trunk...worryg0d:cassandra-sidecar:jackson-validating-deserializer?expand=1]
> RestoreJobConfigurationImpl bypasses validation
> -----------------------------------------------
>
> Key: CASSSIDECAR-504
> URL: https://issues.apache.org/jira/browse/CASSSIDECAR-504
> Project: Sidecar for Apache Cassandra
> Issue Type: Bug
> Components: Configuration
> Reporter: Bohdan Siryk
> Priority: Major
>
> Spotted during review of CASSSIDECAR-501.
> Basically, *RestoreJobConfigurationImpl* is validated only through its
> builder, while Jackson takes another path to instantiate and parse values
> into config object which results in bypassing validation.
> Across the codebase, validation of each config setting is delegated to its
> setters. It's enough for single setting validation, but it's not possible for
> settings that depend on other settings like _jobDiscoveryMinimumRecencyDays_
> of {*}RestoreJobConfigurationImpl{*}. Value _jobDiscoveryMinimumRecencyDays_
> cannot be greater than
> _restoreJobTablesTtl_ value which is configurable. The order of
> deseriazliation is unknown, so we have to validate object right after it is
> deserialized (including calls of setters).
> We can achieve such by hooking into Jackson deserialize chain (using
> {*}BeanDeserializerModifier{*}) and validate object there or just by creating
> an all arg constructor with @JsonCreator annotation so removing all setters
> entirely.
> I tried to implement the first approach with help of AI
> [here|https://github.com/apache/cassandra-sidecar/compare/trunk...worryg0d:cassandra-sidecar:jackson-validating-deserializer?expand=1]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
