This PR adds an interface for the ConnexionMiddleware, similar to the
interface of the Connexion Apps.
The Connexion Apps are now a simple wrapper around the
ConnexionMiddleware and framework app, delegating the work to the
middleware. This enables a similar interface and behavior for users when
using either the middleware or apps.
The arguments are repeated everywhere there is a user interface, but are
parsed in a central place. Repeating the arguments is not DRY, but
needed to provide users with IDE autocomplete, typing, etc. They are
parsed in a single `_Options` class, which also provides a mechanism to
set default options on an App level, and override them on the more
granular API level.
This makes the long list of provided parameters a lot more manageable,
so I would like to use it for the `Jsonifier` as well, and re-add the
`debug` and `extra_files` arguments which I have dropped in previous
PRs. I'll submit a separate PR for this.
I renamed the `options` parameter to `swagger_ui_options` since it only
contains swagger UI options. This is a breaking change though, and we'll
need to highlight this upon release.
We still have quite a lot of `App`, `MiddlewareApp`, and abstract
classes. It would be great if we could find a way to reduce those
further, or at least find better naming to make it more clear what each
one does 🙂 .
Finally, I added examples on how the middleware can be used with third
party frameworks under `examples/frameworks`. Currently there's an
example for Starlette and Quart, but this should be easy to extend. They
also show how the `ASGIDecorator` and `StarletteDecorator` from my
previous PR can be used.
* Added unit tests to demonstrate the problems of https://github.com/zalando/connexion/issues/975
- Taken mostly from existing PR: https://github.com/zalando/connexion/pull/987
* now splitting out multipart POSTs into files[] and form[], handling duplicate keys as the rest of connexion expects
- Based parly on existing PR: https://github.com/zalando/connexion/pull/987
* rewrote how operations/openapi.py::_get_body_argument() works to better build the arguments[] list according to what the spec says and what the handler accepts. This fixes a bug when requests contain mixed files and form values and the handler is expecting variable names matching the request property names.
* Adding unit tests to improve code converage test
* post merge fixes - using 'async' keyword now in new unit test file
* unit test improvements -- now testing the contents of the files we upload too
* making some code a bit clearer regarding duplicate names of file submissions
* fixing up unit tests since merging main
* fixing isort-check-tests and flake8
* clarified a comment
* comment correction
* after discussions with maintainer, reverted _get_body_argument back to the original where it does not attempt to break out the body into individual arguments for the handler. But left in changes that make the normal behavior of not passing a body argument to a handler without one more consistent when the body itself is empty or not an object type.
* fixing unit tests after after reverting _get_body_argument behavior
* Add test for incorrectly cased params with pythonic_params
* Fix 1307: only sanitize when checking view func arguments
* Don't sanitize original request form
* Fix OpenAPI3 test fixture for form data
* Fix view function for test
* #1424: add keywords to the list of pythonic words
* reorder imports
* add test query parameter
* add test query parameter "class"
* add class query param to test
* add class query param to openapi spec
* Update connexion/decorators/parameter.py
Co-authored-by: Ruwann <ruwan.lambrichts@ml6.eu>
Co-authored-by: Ruwann <ruwan.lambrichts@ml6.eu>
* Use more liberal flask converters for float and int
These don't try to enforce a "single representation" of paths but instead try to convert the numbers that callers pass in.
Addresses #1040 and #1041
* Use f-strings instead of string concat or %-formats
* Complying with style rules added long after this PR was made
When using an OAS3 spec with formdata, the validation logic looks
for the key 'formData' in the spec parameters list. This keys is
specific to OAS2, and will never be present, causing any form data to
throw an ExtraParameterProblem.
* 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.
- App and Api options must be provided through the "options" argument (``old_style_options`` have been removed).
- You must specify a form content-type in 'consumes' in order to consume form data.
- The `Operation` interface has been formalized in the `AbstractOperation` class.
- The `Operation` class has been renamed to `Swagger2Operation`.
- Array parameter deserialization now follows the Swagger 2.0 spec more closely.
In situations when a query parameter is passed multiple times, and the collectionFormat is either csv or pipes, the right-most value will be used.
For example, `?q=1,2,3&q=4,5,6` will result in `q = [4, 5, 6]`.
The old behavior is available by setting the collectionFormat to `multi`, or by importing `decorators.uri_parsing.AlwaysMultiURIParser` and passing `parser_class=AlwaysMultiURIParser` to your Api.
- The spec validator library has changed from `swagger-spec-validator` to `openapi-spec-validator`.
- Errors that previously raised `SwaggerValidationError` now raise the `InvalidSpecification` exception.
All spec validation errors should be wrapped with `InvalidSpecification`.
- Support for nullable/x-nullable, readOnly and writeOnly/x-writeOnly has been added to the standard json schema validator.
- Custom validators can now be specified on api level (instead of app level).
- Added support for basic authentication and apikey authentication
- If unsupported security requirements are defined or ``x-tokenInfoFunc``/``x-tokenInfoUrl`` is missing, connexion now denies requests instead of allowing access without security-check.
- Accessing ``connexion.request.user`` / ``flask.request.user`` is no longer supported, use ``connexion.context['user']`` instead
- array logic refactored into one place.
- validation.py and parameter.py no longer try to join the array, and the split it again.
- validation of defaults now works, because the validator is given the correct type.
- some additional classes that change the behavior of deduplicating query parameters that are defined multiple times
- **AlwaysMultiURIParser** that is backwards compatible, warts and all (used by default)
- **Swagger2URIParser** that adheres to the spec's definition of `collectionFormat: multi` and uses the last-defined query parameter value (ex. `query?a=1&a=2` => `a = 2`)
- **FirstValueURIParser** that behaves like Swagger2URIParser, except that the first-defined value is used (ex. `query?a=1&a=2` => `a=1`)
* Preserving the multiplicity of array type query parameters
* Resolved failing tests, and refactored code block into a method
* Added tests for multi array
* Refactored parameter.py and updated tests in test_parameters.py
* Example with Flask support
* Only show import error when trying to use Flask
* Re-organize imports
* Move flask_utils next to related module
* Code style
* Change back to incentivizes
* Includes Flask by default
* Project clean up
* Update Rafael Caricio's e-mail address
* Fix conflicts
Without sanitization e.g. OData query parameters, such as $skip, $top,
$filter cannot be passed to the controller (except by use of **kwargs).
Fixes: zalando/connexion#334
Request validation is enhanced to verify requests only include query or
formData parameters that are specified in the spec.
This validation does not occur for header or path parameters. This is
because most applications probably prefer to ignore extra headers and
a request with extra path parameters would point to a different
endpoint.
