Skip to content
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

Closed
my-name-is-nobody opened this issue Jan 2, 2019 · 5 comments
Assignees
Labels

Comments

@my-name-is-nobody
Copy link

my-name-is-nobody commented Jan 2, 2019

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 file connexion/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):

openapi: "3.0.0"
info:
  title: "Some API"
  version: "0.0.1"
servers:
- url: /
paths:
  /test:
    post:
      operationId: app.test
      requestBody:
        required: true
        content:
          application/json:
            schema:
              x-body-name: body
              type: object
              properties:
                "$id":
                  type: string
      responses:
        200:
          description: Response.

that uses test(body), in app.py, as its handler, which is defined as

import connexion

def test(body):
    import json
    print(json.dumps(body, indent=2))
    return json.dumps(body, indent=2), 200

app = connexion.FlaskApp(
    __name__,
    specification_dir="./")
app.add_api("api.yaml", validate_responses=True)
app.run(port=8080)

Calling the above endpoint with curl -X POST -H "Content-Type: application/json" localhost:5001/test -d '{"$id": "myid"}', the output of the handler test is

{
  "id": "myid"
}

instead of the expected

{
  "$id": "myid"
}

Additional info:

  • python --version:
    Python 3.6.7 :: Anaconda, Inc.

  • pip show connexion | grep "^Version\:":
    Version: 2.2.0

@dtkav dtkav added the bug label Jan 8, 2019
@dtkav
Copy link
Collaborator

dtkav commented Jan 8, 2019

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.

@dtkav dtkav self-assigned this Jan 8, 2019
@adrpar
Copy link

adrpar commented May 15, 2019

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?

ptamilarasan added a commit to sotaog/connexion that referenced this issue Jun 13, 2019
pbasista added a commit to pbasista/connexion that referenced this issue Jul 31, 2019
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.
@pbasista
Copy link
Contributor

I believe that PR #1008 addresses this issue.

@aexvir
Copy link

aexvir commented Jul 31, 2019

@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.

@dtkav
Copy link
Collaborator

dtkav commented Nov 8, 2019

hey @aexvir -
Unfortunately as a community member (not a zalando empolyee) I don't have write permissions to the repo.
I try to provide knowledge, do code review, and fix bugs as I have time available, but I'm unable to merge any PRs.

hjacobs pushed a commit that referenced this issue Dec 3, 2019
* 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants