-
-
Notifications
You must be signed in to change notification settings - Fork 773
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
Sanitization removes sensible characters in API definition and json request body input #835
Comments
Thanks for filing this issue. There are a handful of problems in the validation code that are intertwined. If you have free time - it would be really great if you can write a test case for this. I'm trying to fix the underlying flaws with #760 , and having a robust test suite will help a lot. |
Hi, is there any update on this issue? I am experiencing this bug myself and would like to know if there are plans to have this fixed, or what would be needed to do so? |
The deserialized JSON form of the request body needs to be passed to the client applications * without further modification * so that they can work directly with objects that have been received over the network. The only names for which sanitization makes sense are the ones which are used as Python identifiers. Keys of the top-level JSON object within the request payload are never used by Connexion as Python identifiers. Also, no such sanitization of keys within request body is performed in OpenAPI v2. Closes issue spec-first#835.
I believe that PR #1008 addresses this issue. |
@dtkav @hjacobs It seems that this project doesn't have as much activity as before... I'd like to ask what's the chance of getting this merged and released in a short time frame? This issue is impacting us at the moment. We can't afford waiting another 6 months for the next release, and we need to evaluate what our approach is going to be. I'm seeing other people just forking the project with changes from the open PRs, but we'd like to avoid that if there is a plan to keep making regular releases and take care of the PRs. |
hey @aexvir - |
* Remove the unused "query_sanitazion" fixture * Test whether no sanitization is performed in the request body * Do not perform sanitization on request body keys in OpenAPI v3 The deserialized JSON form of the request body needs to be passed to the client applications * without further modification * so that they can work directly with objects that have been received over the network. The only names for which sanitization makes sense are the ones which are used as Python identifiers. Keys of the top-level JSON object within the request payload are never used by Connexion as Python identifiers. Also, no such sanitization of keys within request body is performed in OpenAPI v2. Closes issue #835.
Description
I am using Connexion v2.2.0 to build an API that handles json schemata.
Request bodies containing schemata with a field name containing characters other than [0-9a-zA-Z_] are removed while parsing the request and passed to the handlers sanitized.
This leads to unexpected behavior.
The sanitization done in method
parameter_to_arg
(in fileconnexion/decorators/parameter.py
) removes sensible characters such as$
that are used in both API definition and json body input such as in fields "$id" and "$schema". Those field names are common in json schematas following version 06, for example.Expected behaviour
For example, a valid json {"$id": "...", ...} is used in the call and it should be passed to the handlers as is.
Actual behaviour
Following the above example, a valid json {"$id": "...", ...} used in the call is passed to the handlers as {"id": "...", ...}.
Steps to reproduce
Assume the following API definition (
api.yaml
):that uses
test(body)
, inapp.py
, as its handler, which is defined asCalling the above endpoint with
curl -X POST -H "Content-Type: application/json" localhost:5001/test -d '{"$id": "myid"}'
, the output of the handlertest
isinstead of the expected
Additional info:
python --version
:Python 3.6.7 :: Anaconda, Inc.
pip show connexion | grep "^Version\:"
:Version: 2.2.0
The text was updated successfully, but these errors were encountered: