Improve additional property validation

[James Navin]

Currently in order to generate errors/warnings about the addition of properties in a request that aren't present in the swagger spec the validator uses the JSON schema "additionalProperties" keyword (it injects it into the schema prior to validation).

This works well for simple schemas, but fails when composition via the allOf keyword is used (see http://stackoverflow.com/questions/22689900/json-schema-allof-with-additionalproperties). This also affects validation of schemas that use discriminator, which by necessity must also use allOf.

It would be nice to support the desired behavior of failing tests in the presence of additional properties without using the additionalProperties keyword that brings with it a lot of complications.

[Fabrice Gabolde]

I have come across this issue (and related others, e.g. https://bitbucket.org/atlassian/swagger-request-validator/issues/208/add-ability-to-ignore-extra-properties-of) while investigating why many of my responses failed validation even though they seemed fine.

It seems swagger-request-validator considers additionalProperties: false to be the default value when unspecified? But reading through the Swagger 2 spec here:

https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#schema-object

it refers to the JSON Schema spec for validation of additional properties, which in turn has this to say:

https://json-schema.org/latest/json-schema-validation.html#rfc.section.6.5.6

"Omitting this keyword has the same behavior as an empty schema." (which is also the behavior of additionalProperties: true, since true is a JSON Schema that always passes validation).

So it seems swagger-request-validator is doing the opposite of the intent of Swagger 2 here? I can’t speak for OpenAPI v3 as I haven’t spent any appreciable time using it.

I understand suddenly switching to defaulting to additionalProperties: true would break backwards compatibility, and or possibly the authors chose false as a default on purpose (after all it fits better with some situations), so might it be a configuration option instead? The solution proposed in #208, to lower the severity of additionalProperties violations, is not entirely satisfactory; I still want to raise validation errors on invalid additionalProperties after all.

[James Navin]

Resolving this issue and moving discussion to #271