-
Notifications
You must be signed in to change notification settings - Fork 54
parameters provided a $ref skip the jsonschema validation #165
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
Labels
Comments
fredbi
added a commit
to fredbi/validate
that referenced
this issue
Dec 23, 2023
This PR applies an extra jsonschema validation to expanded parameters. Whenever a parameter is provided as a $ref, jsonschema validation works at the level of the unexpanded parameter only. It is indeed valid to declare a parameter as a json reference. The issue is that the contents of this parameter definition are subject only to "extra rules" (uniqueness, etc) and not the basic jsonschema rules (e.g. required properties). An example is provided by go-swagger/go-swagger#2527. It seems that this situation never occured before go-swagger/go-swagger#2527 because the "parameters" section to which shared parameters normally point to is always fully expanded. In the case of a $ref to a schema in "definition", the invalid content of the $ref incorrectly passes validation. * fixes go-openapi#165 * contributes go-swagger/go-swagger#2527 Signed-off-by: Frederic BIDON <[email protected]>
fredbi
added a commit
to fredbi/validate
that referenced
this issue
Dec 24, 2023
This PR applies an extra jsonschema validation to expanded parameters. Whenever a parameter is provided as a $ref, jsonschema validation works at the level of the unexpanded parameter only. It is indeed valid to declare a parameter as a json reference. The issue is that the expanded content of this parameter definition is subject only to "extra rules" (uniqueness, etc) and not to the basic jsonschema rules (e.g. allowed and required properties). An example is provided by go-swagger/go-swagger#2527. It seems that this situation never occured before go-swagger/go-swagger#2527 because the "parameters" section to which shared parameters normally point to is always fully expanded. In the case of a $ref to a schema in "definition", the invalid content of the $ref incorrectly passes validation. * fixes go-openapi#165 * contributes go-swagger/go-swagger#2527 Signed-off-by: Frederic BIDON <[email protected]>
fredbi
added a commit
to fredbi/validate
that referenced
this issue
Dec 27, 2023
This PR applies an extra jsonschema validation to expanded parameters. Whenever a parameter is provided as a $ref, jsonschema validation works at the level of the unexpanded parameter only. It is indeed valid to declare a parameter as a json reference. The issue is that the expanded content of this parameter definition is subject only to "extra rules" (uniqueness, etc) and not to the basic jsonschema rules (e.g. allowed and required properties). An example is provided by go-swagger/go-swagger#2527. It seems that this situation never occured before go-swagger/go-swagger#2527 because the "parameters" section to which shared parameters normally point to is always fully expanded. In the case of a $ref to a schema in "definition", the invalid content of the $ref incorrectly passes validation. * fixes go-openapi#165 * contributes go-swagger/go-swagger#2527 Signed-off-by: Frederic BIDON <[email protected]>
fredbi
added a commit
that referenced
this issue
Dec 27, 2023
* fix(parameters): applied extra schema validation to parameters This PR applies an extra jsonschema validation to expanded parameters. Whenever a parameter is provided as a $ref, jsonschema validation works at the level of the unexpanded parameter only. It is indeed valid to declare a parameter as a json reference. The issue is that the expanded content of this parameter definition is subject only to "extra rules" (uniqueness, etc) and not to the basic jsonschema rules (e.g. allowed and required properties). An example is provided by go-swagger/go-swagger#2527. It seems that this situation never occured before go-swagger/go-swagger#2527 because the "parameters" section to which shared parameters normally point to is always fully expanded. In the case of a $ref to a schema in "definition", the invalid content of the $ref incorrectly passes validation. * fixes #165 * contributes go-swagger/go-swagger#2527 Signed-off-by: Frederic BIDON <[email protected]> * added unit test to assert that no duplicate messages are spewed out Signed-off-by: Frederic BIDON <[email protected]> --------- Signed-off-by: Frederic BIDON <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Whenever a parameter is provided as a $ref, jsonschema validation works at the level of the unexpanded parameter only.
It is indeed valid to declare a parameter as a json reference.
The issue is that the contents of this parameter definition are subject only to "extra rules" (uniqueness, etc) and not the basic jsonschema rules (e.g. required properties).
An example is provided by go-swagger/go-swagger#2527.
The following spec is VALID. However, its expanded version is of course not valid.
It seems that this situation never occured before go-swagger/go-swagger#2527 because the "parameters" section to which shared parameters normally point to is always fully expanded (and similarly for shared responses).
In the case of a $ref to a schema in "definition", the invalid content of the $ref incorrectly passes validation.
The section:
refers to a definition where "name" and "in" are missing:
The text was updated successfully, but these errors were encountered: