Closed MattMCloudy closed 4 years ago
This only prevents at the top level. However additionalProperties
is a valid entity all the way down the tree wherever a schema declares "type": "object"
This is really the hard bit. It means schema authors have to add "additionalProperties": "false"
throughout their schema. Would prefer to think up a smarter way to address this problem.
This only prevents at the top level. However
additionalProperties
is a valid entity all the way down the tree wherever a schema declares"type": "object"
This is really the hard bit. It means schema authors have to add
"additionalProperties": "false"
throughout their schema. Would prefer to think up a smarter way to address this problem.
I agree, it would be much better if there was a way to have everit make "additionalProperties": "false"
be the default behavior.
For the purpose of closing this on the side of enforcing the contract, let's add the restriction through the schema tree. We can work out a smarter way to achieve same later. I'd rather this then having to break a resource provider later.
I'll run pre-commit and post a new revision with the changes.
Issue #, if available: #33
Description of changes: This commit adds
additionalProperties
as a required field inside of theprovider.definition.schema.v1.json
meta-schema. This will allow the checks here to be enforced whenadditionalProperties
is not defined. As it is now, the properties can be added to instances of the schema which are not tracked inside of the registered schema.By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.