-
-
Notifications
You must be signed in to change notification settings - Fork 767
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
Move JSON response body validation to middleware #1591
Conversation
connexion/validators.py
Outdated
await self._send(self._messages.pop(0)) | ||
|
||
|
||
class TextResonseBodyValidator(JSONResponseBodyValidator): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why does the validator for content type text/plain
subclass from the JSON validator?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume to maintain compatibility?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The response body in the spec is defined as a json schema, so we can use jsonschema
to validate text/plain
responses as well. We can even use json.loads
to cast non-string values (eg. json.loads("2.0") = 2.0
), but json.loads
fails for text strings (eg. json.loads("text")
), so we should catch any decode errors.
VALIDATOR_MAP = { | ||
"parameter": ParameterValidator, | ||
"body": {"application/json": JSONRequestBodyValidator}, | ||
"response": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This has the side-effect that we cannot simply do a .update()
on the validator map of a specific instance as it only goes 1 level deep. Currently, still done here:
and
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch. Question is what kind of behavior we want here. I do think we want to update at the top level, as it would otherwise be impossible to remove validators. That just means the user needs to include all validators they want to use in their custom validator_map.
Pull Request Test Coverage Report for Build 3177325520
💛 - Coveralls |
2148dad
to
dde3dd3
Compare
This PR moves the JSON response body validation to middleware as another step towards #1525.
I moved away from having the body validators implement the complete ASGI interface and calling the next app as mentioned in #1588, as this is not possible for the response validators. We only know the response content type once the response has started, so we can't wrap the validator around the next app.
Instead, the validator now provides a wrapped receive / send callable depending on if it validates either request or response bodies. I updated the request body validator to match this.