Number formats validated on a warning level only
For given OpenAPI 3.x schema:
Pet:
type: object
properties:
age:
type: integer
format: int32
and JSON payload e.g.:
{ "age": 999999999999999999999999999999999 }
I would expect validator to report some reasonable problem that the number used in payload is not a 32-bit signed integer (like it's defined in OpenAPI 3.x specification), but the validator reports nothing. The reason is that Int32Attribute is reported only on warning level which is not reflected to a final validation report. This also applies to int64
, float
and double
formats.
Is this expected behaviour? If it is, is there any possibility how to enable reporting for these number formats using OpenApiInteractionValidator as main validation component and without any additional custom validation?
Comments (5)
-
-
Well, even formats are not mandatory in OpenAPI 3.X, the validator documentation says that they are supported. See Supported Data Type Formats section in OpenAPI v3 Specification Support document.
-
Thanks for doing the investigation - much appreciated!
The preferred approach for controlling the level at which messages are reported is via the “levels” mechanism - see the README in https://bitbucket.org/atlassian/swagger-request-validator/src/master/swagger-request-validator-core/ for details on how this is configured if you aren’t familiar with it. Ideally whatever solution we come up with can be controlled with this mechanism.
Without having looked at it too deeply Id say your option (4) would be the preferred way. It would probably look something like:
- Change the attributes to emit error level messages
- Update
default-levels.properties
to set them back to WARN level by default (but then allow users who want to to increase that to ERROR level via the normal mechanism)
The complication you may run into is that the levels mechanism will use a key of the form
validation.<request|response>.<body|parameter>.schema.<keyword>
` and in this casekeyword
will beformat
for all types. If you wanted/needed to differentiate which format was in error you might need to adjust how the key is created - perhaps simply appending the type on the end would work since those levels are hierarchical.Hope this helps - more than happy to discuss further.
Cheers,
James
-
Actually - the more I think on it the more I'm inclined to say leave them at ERROR level and allow people to turn them off if they don’t want them on.
-
- changed status to resolved
Available in v2.10.0
- Log in to comment
I was examining the situation and here is what I found:
But currently it’s hard to make those validations reported even only optional cause of following reasons:
So far the analysis. In case somebody of maintainers gives me the feedback which way is the wanted/feasible one, I will be happy to contribute the code.