Expected Behavior

Add BigDecimal type into SecurityJackson2Modules as allowed class

Current Behavior

It needs to add mixins or annotations if the BigDecimal field exists in a class

Context

I don't see a clear reason why Date, Url or Instant are allowed by default but BigDecimal is not. I can't say that problem is really crucial for me but definitely, it would be more convenient to have all such types allowed by default.

Comment From: jzheaux

Thanks for the suggestion, @usharik. It does not allow BigDecimal since Spring Security domain objects don't need it.

The concern with adding this or that type to the allowlist upon request is that it turns the project into a gatekeeper for allowed types, which we don't want to do.

Comment From: usharik

Ok. I see.

@jzheaux may I ask a couple of questions. First of all is there some official guide about usage of Spring Security with Spring Session? Probably some best practics or code examples? I was very surprised by having such issue.

Comment From: jzheaux

There is the Spring Session reference, but I think I need to understand your question better to give a better answer. Can you explain what using Spring Security and Spring Session together has to do with Jackson serialization not allowing BigDecimal by default?

Comment From: usharik

To make it working I need to put some annotations to BigDecimal field like here https://github.com/usharik/geek-eshop-08-04/blob/master/shop-backend-api-app/src/main/java/ru/geekbrains/controller/dto/ProductDto.java

Also possible to use Jackson mixins or simply convert BigDecimal field to String. All that is not something impossibly hard but I'm feeling that code could be much better without all these workarounds. From my point of view all primitive-like types from JDK including String, Data, LocalDatetime or BigDecimal should be serialized without any additional workarounds. That's expected behaviour for me. If it's not it should be somehow explained or documented.

Comment From: mentallurg

It is absolutely correct that the issue is closed. The purpose of the SecurityJackson2Modules is to support serialization into JSON for security related classes like OAuth2AuthenticationToken, RememberMeAuthenticationToken, AuthenticatedPrincipal, GrantedAuthority, OidcUserInfo etc.

The ProductDto referred by @usharik has definitely nothing to do with security. To serialize any objects that are not related to the Spring security into Spring session in JSON format one should correspondingly configure the Jackson ObjectMapper. If needed, custom serializers and deserializers should be implemented. But Jackson already provides out of the box serializers and deserializers for many types including BigDecimal. Again, one should only configure ObjectMapper properly if default configuration does not fit the expectations.

Besides configuring ObjectMapper, one should use corresponding annotations for JSON serialization where appropriate. And one should keep in mind mixins.

Again, I don't see any reason to extend SecurityJackson2Modules for non-security purposes. This issue should remain closed.

Comment From: usharik

@mentallurg BigDecimal is not from "many types". That's a standard and widely used type for fixed point numbers and such workarounds with Jakson makes code unnecessary complex and ugly. No objections about any custom types. I understand the reasons why shall we explicitly mark them for serialization. But I believe that no standard semi-primitive classes from JVM should cause such issues.

Comment From: mentallurg

@usharik : 1) No, BigDecimal is one of many types supported by Jackson out of the box. Jackson provides classes BigDecimalSerializer and BigDescimalDeserializer. If they don't suit your needs, feel free to implement your own serializers and deserializers or your own module that encapsulates it.

2) Independent on serializers and deserializers: BigDecimal as well as ProductDto have nothing to do with security. That's why SecurityJackson2Modules does not need any extension for these classes.