Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add MapperFeature.REQUIRE_TYPE_ID_FOR_SUBTYPES to enable/disable strict subtype Type Id handling #3853

Closed
stevestorey opened this issue Mar 30, 2023 · 8 comments · Fixed by #3854
Milestone

Comments

@stevestorey
Copy link
Contributor

stevestorey commented Mar 30, 2023

Describe the bug
In 2.14, if you setup @JsonTypeInfo(use = Id.NAME) then all JSON passed to readValue must include the @type information, but that's no longer true in 2.15, which will now unmarshall JSON with missing type information (as long as no other constraints fail). Although I guess it's possibly something to consider as an improvement, but personally I would like to ensure that clients must pass the type information, not least so that one cannot accidentally send the wrong JSON, but have it pass because it's close enough to the intended type.

Version information
2.15.0-rc2

To Reproduce

Unit test:

import static org.assertj.core.api.Assertions.assertThat;
import static org.junit.jupiter.api.Assertions.assertThrows;

import org.junit.jupiter.api.Test;

import com.fasterxml.jackson.annotation.JsonTypeInfo;
import com.fasterxml.jackson.annotation.JsonTypeInfo.Id;
import com.fasterxml.jackson.annotation.JsonTypeName;
import com.fasterxml.jackson.databind.ObjectMapper;
import com.fasterxml.jackson.databind.exc.InvalidTypeIdException;

public class RegressionTest {
    
    @Test
    public void testTypeRequired() throws Exception {
        ObjectMapper om = new ObjectMapper();
        DoSomethingCommand cmd = om.readValue("{\"@type\":\"do-something\"}", DoSomethingCommand.class);
        assertThat(cmd).isNotNull();
        // Prove that we can't load the command _without_ the type information
        // This assertion passes in 2.14, but fails in 2.15 as nothing is thrown and the instance
        // is unmarshalled anyway
        assertThrows(InvalidTypeIdException.class, () -> om.readValue("{}", DoSomethingCommand.class));
    }
}

@JsonTypeInfo(use = Id.NAME)
interface Command {
}

@JsonTypeName("do-something")
class DoSomethingCommand implements Command {
}

/*
 * This highlights why I think it's dangerous to accept the JSON with no type information. A
 * client might accidentally send this structure, but without the type information, which would
 * be rejected in 2.14, but with 2.15 it would be accepted (incorrectly IMHO)
 */
@JsonTypeName("do-something-else")
class DoSomethingElseCommand extends DoSomethingCommand {
}

Expected behavior

The unit test passes, as an InvalidTypeIdException is thrown when no type information is present in the incoming JSON, as was the case in 2.14

@stevestorey stevestorey added the to-evaluate Issue that has been received but not yet evaluated label Mar 30, 2023
@cowtowncoder
Copy link
Member

cowtowncoder commented Mar 31, 2023

The reason here is that you are not using target type of Command but concrete implementation type -- and fix here is for #2968 (PR #3803), a particularly highly voted issue.
If target type was Command, an exception would be thrown; defaulting only occurs at inheritance levels higher than @JsonTypeInfo (subtype).

I would be open to having a MapperFeature to allow Strict handling of Type Ids, if anyone has time. But it'd have to be added rather quickly to get into 2.15.0.

@cowtowncoder cowtowncoder added 2.15 and removed to-evaluate Issue that has been received but not yet evaluated labels Mar 31, 2023
stevestorey added a commit to stevestorey/jackson-databind that referenced this issue Mar 31, 2023
Resolves FasterXML#3853 by
adding support for strict handling of type information when
deserializing into a registered subtype.
stevestorey added a commit to stevestorey/jackson-databind that referenced this issue Mar 31, 2023
Resolves FasterXML#3853 by
adding support for strict handling of type information when
deserializing into a registered subtype.
@stevestorey
Copy link
Contributor Author

I've created #3854 to add some support for it if there's still time ?

@cowtowncoder
Copy link
Member

Thank you @stevestorey -- yes, I think there is. I'll have to think about the question of default settings: in principle, I agree that changes should ideally be Opt-In. The only caveat here is that this is a highly-voted improvement and in some ways it's... one possibility would be to introduce it in 2.15, defaulting to old behavior; then consider change in 2.16; this to have new MapperFeature available bit earlier to make opt-out easier.

Thank you for submitting #3854: I will try to find time to work with it, and will make sure to tackle it before 2.15.0-rc3 gets released.

@cowtowncoder cowtowncoder changed the title 2.15 no longer throws InvalidTypeIdException for missing type info Add MapperFeature.REQUIRE_TYPE_ID_FOR_SUBTYPES to enable/disable strict subtype Type Id handling Apr 12, 2023
@cowtowncoder cowtowncoder added this to the 2.15.0-rc3 milestone Apr 12, 2023
@cowtowncoder
Copy link
Member

cowtowncoder commented Apr 12, 2023

Also realizing that maybe for 2.16 there should be added property for @JsonTypeInfo to indicate whether strict type id handling should be enabled for specific base type and its subtypes or not -- should be OptBoolean valued for backwards compatibility.

Created #3877 for possible follow-up work as per my comment.

/cc @JooHyukKim

@cowtowncoder
Copy link
Member

Thank you again @stevestorey -- this is merged and will make it in 2.15.0-rc3 that I hope to release RSN.

@Yash-Kudesia
Copy link

@cowtowncoder is the fix for #2968 released in 2.15.0-rc3?

As even after upgrading the version, we are getting the prev errors.

@JooHyukKim
Copy link
Member

JooHyukKim commented Apr 18, 2023

@Yash-Kudesia By looking at the release note (refer to below), yes this issue should have been fixed by 2.15.0-rc3 🥲.
Could you double check the depedency configurations or provide reproducible test so maybe I can help?

#3853: Add `MapperFeature.REQUIRE_TYPE_ID_FOR_SUBTYPES` to enable/disable

@cowtowncoder
Copy link
Member

Correct: while the fix is in, it will only work when that MapperFeature ^^^ is explicitly DISABLED (is enabled by default).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants