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