networknt / networknt/json-schema-validator

oneOf and discriminator value mismatch doesnot fail

Open
#1,225 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Java
Stars
1.1k
Forks
352
Avg merge
3d 13h
Merged PRs (30d)
5

Description

This is kind of similar to https://github.com/networknt/json-schema-validator/issues/1087

Here's an example test case that highlights the problem:

    @Test
    void oneOfDiscriminatorEnabledWithDiscriminatorMismatch() {
        String schemaData = "{\r\n"
                + "  \"discriminator\": {\r\n"
                + "    \"propertyName\": \"type\",\r\n"
                + "    \"mapping\": {\r\n"
                + "      \"string\": \"#/$defs/string\",\r\n"
                + "      \"number\": \"#/$defs/number\"\r\n"
                + "    }\r\n"
                + "  },\r\n"
                + "  \"oneOf\": [\r\n"
                + "    {\r\n"
                + "      \"$ref\": \"#/$defs/string\"\r\n"
                + "    },\r\n"
                + "    {\r\n"
                + "      \"$ref\": \"#/$defs/number\"\r\n"
                + "    }\r\n"
                + "  ],\r\n"
                + "  \"$defs\": {\r\n"
                + "    \"string\": {\r\n"
                + "      \"properties\": {\r\n"
                + "        \"type\": {\r\n"
                + "          \"type\": \"string\"\r\n"
//                + "          \"enum\": [\"string\"]\r\n"
                + "        },\r\n"
                + "        \"value\": {\r\n"
                + "          \"type\": \"string\"\r\n"
                + "        }\r\n"
                + "      }\r\n"
                + "    },\r\n"
                + "    \"number\": {\r\n"
                + "      \"properties\": {\r\n"
                + "        \"type\": {\r\n"
                + "          \"type\": \"string\"\r\n"
//                + "          \"enum\": [\"number\"]\r\n"
                + "        },\r\n"
                + "        \"value\": {\r\n"
                + "          \"type\": \"number\"\r\n"
                + "        }\r\n"
                + "      }\r\n"
                + "    }\r\n"
                + "  }\r\n"
                + "}";
        Schema schema = SchemaRegistry.withDialect(Dialects.getOpenApi31()).getSchema(schemaData);
        // intended to be invalid because mapping points to string, but it's validating against number type
        String inputData = "{\r\n"
                + "  \"type\": \"string\",\r\n"
                + "  \"value\": 1\r\n"
                + "}";

        // this passes
        assertEquals(Collections.emptyList(), schema.validate(inputData, InputFormat.JSON));
    }

In this example, passing in {"type": "string", "value": 1} passes because this technically is a valid number schema and an invalid string schema. So the oneOf validation correctly passes (only one schema matches), but it's the wrong schema that matches.

I couldn't find anything definitive when reviewing the open api spec to see if this situation was addressed. it feels like this should be an error? but not sure.

This can be resolved by just adding an enum to each schema's discriminator type.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by running the supplied oneOfDiscriminatorEnabledWithDiscriminatorMismatch test case and review the SchemaRegistry.withDialect(Dialects.getOpenApi31()) entry point. Trace how discriminator-enabled oneOf validation selects a branch, then confirm the expected OpenAPI behavior before adding a regression test that distinguishes the mapped schema from another matching schema.

Written by the indexing model from the issue text.

Assessment

Tech stack
java, openapi
Domain
api, testing-qa
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
42/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.