Hide fields conditionally

[Christian]

Dear Jackson community,

we are trying to enhance the Jackson serializer in one of our project. We want to hide / ignore certain fields from certain objects conditionally. Means certain fields should only be serialized to JSON when a specific condition is true. We want to restrict certain fields based on the current user access.

Our idea is to pass a auth context to Jackson, this auth context will contain information which fields the current user can see and which not.

The difficult part now comes how we can hide certain fields based on this.

What we already considered:

• JsonIgnore annotation (does not work, its static and not based on conditions)
• JsonInclude annotation (does not work, its static and not based on conditions)
• JsonView (not very practical, we would need to create one view class for each field in all objects)
• Using custom serializer as described here https://www.baeldung.com/jackson-serialize-field-custom-criteria#2-custom-serializer (Can only work to hide a complete object, not just certain fields)

Does anyone has a good approach in Jackson to exclude / hide / ignore certain fields dynamically?

[Tatu Saloranta]

Aside from these approaches, there are couple more, included here:

http://www.cowtowncoder.com/blog/archives/2011/02/entry_443.html

and probably most specifically use of "JsonFilter":

http://www.cowtowncoder.com/blog/archives/2011/09/entry_461.html

which is more dynamic but less manual than custom serializer.

Aside from this a different approach would be to use two-phase approach where:

1. POJO is converted into JsonNode (JsonNode n =
mapper.valueToTree(pojo);) first, and
2. Filtering logic is implemented on JsonNode (remove entries based on
whatever criteria; or change/rename; add)

and then the resulting JsonNode is serialized. I think this is a quite
widely used technique especially when step (2) is based
on a list of fields to include passed from external sources (like as
request parameter).

I hope this helps,

-+ Tatu +-

[Christian]

Using JsonFilter annotation and having a FilterProvider which is creating dynamic filters in the background seems a good option.

Just saw the BeanPropertyFilter is being deprecated in favor of PropertyFilter. My first guess was writing the new filter directly based on PropertyFilter, but seems the provider still needs to return BeanPropertyFilter. 
There is just one BeanPropertyFilter to PropertyFilter converting method, but not the other way around? So we would need to build a filter based on the deprecated BeanPropertyFilter?

[Tatu Saloranta]

On Tue, Sep 29, 2020 at 5:24 AM 'Christian' via jackson-user
<jackso...@googlegroups.com> wrote:
>
> Using JsonFilter annotation and having a FilterProvider which is creating dynamic filters in the background seems a good option.
>
> Just saw the BeanPropertyFilter is being deprecated in favor of PropertyFilter. My first guess was writing the new filter directly based on PropertyFilter, but seems the provider still needs to return BeanPropertyFilter.
> There is just one BeanPropertyFilter to PropertyFilter converting method, but not the other way around? So we would need to build a filter based on the deprecated BeanPropertyFilter?

No, BeanPropertyFilter will be dropped in 3.0, and while it was left
in 2.x (deprecated since 2.3) that was purely for backwards
compatibility.
It should not be implemented directly by new code.

But to keep that compatibility, FilterProvider may look odd -- see
`SimpleFilterProvider.java` for how things should work.
You can often just use that as provider implementation.

So I'd implement `PropertyFilter` and use or sub-class `SimpleFilterProvider`.

-+ Tatu +-

> --
> You received this message because you are subscribed to the Google Groups "jackson-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jackson-user...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-user/c4c4cc2e-b11f-4f73-a7a5-7e57c397061en%40googlegroups.com.