This repository has been archived by the owner on Nov 19, 2023. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 24
Incorrect validation for additionalProperties? #245
Comments
Hi there. Thanks for the detailed analysis. I think you are correct. We would very much appreciate a PR 😉 |
idesoto-rover
added a commit
to idesoto-rover/drf-openapi-tester
that referenced
this issue
Dec 17, 2021
sondrelg
added a commit
that referenced
this issue
Dec 18, 2021
…validation #245 fix validation for additionalProperties
Finally released v1.3.11 now with the fix. Thanks a lot for the report and fix @idesoto-rover! @Goldziher and me also wanted to also ask if you, by chance, would be interested in helping us maintain the project? Neither one of us work with a tech stack where we get to use the project at the moment, so if you're interested we would be happy to include you 👏 It wouldn't necessarily mean more than reviewing the occasional PR. |
Yes, I'm ok with helping reviewing or testing PRs 👍 I can't guarantee reacting quickly to PRs though, but I'll do my best 😃 |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Hello!
According to https://swagger.io/docs/specification/data-models/dictionaries/, you can specify a dictionary that contains string values like this:
If the dictionary can contain any type of value, you would specify it as either of these two options:
Currently,
drf-openapi-tester
only considers valid theadditionalProperties: true
option because of this line of code that only considers extra keys valid ifadditionalProperties
istrue
.When
additionalProperties
is a dictionary, the code is checking whether the keys are defined insideadditionalProperties
, but I don't think this is correct. I think the correct validation would be: ifadditionalProperties
is a dictionary, validate that the values for any keys that are not defined in theproperties
section match the schema defined in additionalProperties. So for example, in the first example above we would just be validating that values are of typestring
. If the schema foradditionalProperties
is of typeobject
, then we validate that the value matches that object specification (the value itself contains the keys specified in theproperties
section of theadditionalProperties
schema).Let me try to show an example using an
additionalProperties
of typeobject
:For this schema:
This data should be valid:
But not this one because
key_2
andkey_3
are supposed to belong to the values of any extra keys, but not to the object itself. The validation error here should be that we were expecting anobject
for keys that are notkey_1
but we got astring
:And the error here is that it's missing
key_1
which is specified in the schema:I could try to fix this myself, but I would like confirmation that I'm not misunderstanding something and that what I describe should be the expected behaviour.
Thanks!
The text was updated successfully, but these errors were encountered: