Skip to content

OpenAPI validation does not fail when incorrect types are passed in the Request Body #64

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
ddobrin opened this issue Dec 4, 2018 · 0 comments

Comments

@ddobrin
Copy link
Contributor

ddobrin commented Dec 4, 2018

When an OpenAPI YAML file declares a field as an integral type in the request Body, the field could be declared for example as:
...
xyzID:
description: The Internal ID of XYZ that, within the app, uniquely identifies the specific XYZ record.
type: integer
format: int64
example: 911015108
...
The code would map to a Long value and expect that the openapi validation would catch it if somebody were to send in:
...
xyzID: "37983739"
...

Other formats could be used, such as int32, for example.

The code doesn't fail, as a change in the schema validator for handling path and query parameter treats both as idempotent, and the same validator is used:
networknt/json-schema-validator#101

APIs business logic or other cross-cutting concerns wired into the handler chain after openapi-validation would fail.

Recommended solution is to pass in the RequestValidator class in openapi-validator a parameter to the schemavalidator call, see line 112, to segregate between the handling of such values in path/query vs Body.

Request is to address it for all numeric types.

BalloonWen added a commit to BalloonWen/light-rest-4j that referenced this issue Dec 11, 2018
-Implement light-rest-4j networknt#64 for Swagger ValidatorHandler
stevehu added a commit to networknt/json-schema-validator that referenced this issue Dec 12, 2018
# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

No branches or pull requests

1 participant