Closed NGEfreak closed 5 years ago
From the way I read it, non of the cases works as you expect, since you don't have "type". It's really weird, but detection of "type" only applies if the input data is matching the rules. Look here for an example acceptance test: https://github.com/mojolicious/json-validator/blob/master/t/draft4-tests/minProperties.json#L22
Please let me know where in the spec where this has changed, if that is the case.
When it comes to the "null" cases, I just fixed that in the commit above.
The reason why this issue has so many labels is because you reported so many bugs in one issue.
Validation of a request body that requires a object does not work as expected in these cases:
Here is a test script:
Regarding 1. and 2.
The null and invalid JSON testcases fail because of line 308.
Before this line the value of
$body_schema
isAfterwards the value of the variable is
The "required" key is lost at this point with the result that the method
_validate_request_value
returns too early on line 322.Regarding 2.
After this problem is fixed, invalid JSON and Null would still produce the same error:
Expected object - got null.
Invalid JSON is treated as Null/Undef because the methodjson
ofMojo::Message::Request
returns undef in both cases. IMHO, it would be more helpful when there is a different error message in the case of invalid JSON.Regarding 3.
The array testcase fails because the schema does not explicitly state that the type is an object. When I add
type: object
to the request body schema in the spec it works.I could not find in the OpenAPI specification if the type key is optional or required. However, Swagger UI/Editor and JSON::Validator do not complain that the type key is missing. Also, it looks like Swagger UI/Editor sets the type to object implicitly in this case.