Add Jackson 3 support and deprecate Jackson 2 one #17832
Conversation
Signed-off-by: Sébastien Deleuze <sdeleuze@users.noreply.github.com>
This commit adds support for Jackson 3 which has the following major differences with the Jackson 2 one: - jackson subpackage instead of jackson2 - Jackson type prefix instead of Jackson2 - JsonMapper instead of ObjectMapper - For configuration, JsonMapper.Builder instead of ObjectMapper since the latter is now immutable - AllowlistTypeResolverBuilder in new a public type in order to be used easily with the JsonMapper.Builder API Jackson 3 changes compared to Jackson 2 are documented on FasterXML/jackson-future-ideas#72. Signed-off-by: Sébastien Deleuze <sdeleuze@users.noreply.github.com>
Signed-off-by: Sébastien Deleuze <sdeleuze@users.noreply.github.com>
spring-projects-issues
added
the
status: waiting-for-triage
There was a problem hiding this comment.
Thanks for the pull request. Generally, I think this is looking good. I've provided some feedback inline.
It also appears that there are still some classes that need migrated. Searching for jackson on main should give you a complete list of classes that are using jackson.
For example, webauthn has jackson support. I'm guessing this was missed because it is inconsistent with the rest of the jackson support in that it is in a jackson package rather than jackson2. It is also automatically registered because it does not use default types which would make it insecure.
There are also some tests that still use ObjectMapper or deprecated Spring Framework Jackson 2 classes (e.g. JwtDecodersTests.java#L388). Unless the test is specifically for the Jackson 2 support, we should update these to use non-deprecated classes (e.g. JsonMapper).
There are various Spring framework jackson based classes that have been deprecated that we should migrate away from. For example, MappingJackson2HttpMessageConverter usage (e.g. WebAuthnAuthenticationFilter.converter) should be migrated to JacksonJsonHttpMessageConverter if jackson 3 is on the classpath. Likely there could be a static factory method used that Spring Security uses to obtain the correct default json converter instance.
|
|
||
| @Override | ||
| public void setupModule(SetupContext context) { | ||
| ((MapperBuilder<?, ?>) context.getOwner()).setDefaultTyping(new AllowlistTypeResolverBuilder()); |
There was a problem hiding this comment.
This approach appears to create a new instance of AllowlistTypeResolverBuilder for every module. Is that necessary or do we only want a single instance?
| * @author Hyunmin Choi | ||
| * @since 7.0 | ||
| */ | ||
| abstract class AbstractUnmodifiableCollectionDeserializer<T> extends ValueDeserializer<T> { |
There was a problem hiding this comment.
I wonder if there is better built in support for unmodifiable collections now?
| * @author Rob Winch | ||
| * @since 7.0 | ||
| */ | ||
| public class AllowlistTypeResolverBuilder extends DefaultTypeResolverBuilder { |
There was a problem hiding this comment.
Is there a reason that this is now public vs being encapsulated as it is for the Jackson 2 support?
| * @author Rob Winch | ||
| * @since 7.0 | ||
| */ | ||
| public class AllowlistTypeResolverBuilder extends DefaultTypeResolverBuilder { |
There was a problem hiding this comment.
I think that now is a good time for Spring Security to stop using global default typing.
While the AllowlistTypeResolverBuilder worked well as a security patch in the Jackson 2 support, I think that we should remove it for Jackson 3 support and better align with best practices with Jackson. Instead, I think that we should use https://github.com/FasterXML/jackson-docs/wiki/JacksonPolymorphicDeserialization#12-per-class-annotations This would mean that users would need to take the risk of enabling global default typing or opt into default typing per type.
I'd like to ensure that we have a test that verifies that a custom type does not just work after applying Spring Security's module. Another test would verify that users could add their own type. The docs would be updated to explain that global default typing is off, why it is off, and how they can add their own types.
|
|
||
| @Override | ||
| public void setupModule(SetupContext context) { | ||
| // TODO Is it expected that default typing in not configured in the Jackson 2 |
There was a problem hiding this comment.
This is not expected, but please see my comment about no longer enabling global default typing.
| @@ -50,6 +54,7 @@ public Saml2Jackson2Module() { | |||
|
|
|||
| @Override | |||
| public void setupModule(SetupContext context) { | |||
| // TODO Is it expected that default typing in not configured here? | |||
There was a problem hiding this comment.
This is not expected, but please see my comment about no longer enabling global default typing.
This PR adds support for Jackson 3 which has the following major differences with the Jackson 2 one:
jacksonsubpackage instead ofjackson2Jacksontype prefix instead ofJackson2JsonMapperinstead ofObjectMapperJsonMapper.Builderinstead ofObjectMappersince the latter is now immutableAllowlistTypeResolverBuilderin new a public type in order to be used easily with theJsonMapper.BuilderAPIJackson 3 changes compared to Jackson 2 are documented on FasterXML/jackson-future-ideas#72.
It also deprecates Jackson 2 support for removal.
There are TODO comments in
SamlJacksonModuleandSaml2JacksonModuleto review.