Working towards #1709
I think we're almost there, some tests I did are now working properly.
Would love to get some feedback/ideas on the implementation and the
tests :)
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.
* Fix for bug of the function is_json_mimetype() (#1114)
* Splitting the mimetype correctly
* Added a test for the json mimetype usecases
* Update connexion/utils.py
Co-authored-by: Ruwann <ruwan.lambrichts@ml6.eu>
* Fixes util.deep_get when obj is a list
The example below will seem strange. It's the result of distilling a complex
API spec down to the root cause of the issue.
```yaml
---
openapi: 3.0.0
info:
version: v0
title: Repo an error
description: Extremely contrived, but it illustrates the problem
paths:
/:
get:
operationId: app.get
responses:
'200':
description: Just for giggles
content:
application/json:
schema:
$ref: "#/components/schemas/SomeWeirdResource"
components:
schemas:
Resource:
allOf:
- type: object
properties:
id:
type: string
SomeWeirdResource:
allOf:
- type: object
properties:
id:
$ref: '#/components/schemas/Resource/allOf/0/properties/id'
```
While convoluted, this is a valid OpenAPI 3 spec.
```sh
$ yarn swagger-cli validate openapi/my_api.yaml
yarn run v1.17.3
$ /[redacted]/node_modules/.bin/swagger-cli validate openapi/my_api.yaml
openapi/my_api.yaml is valid
✨ Done in 0.23s.
```
`utils.deep_get` assumes the obj to be a dictionary when it can also be a list.
* Updates docstring for utils.deep_get
Comment on the pull request was asking for an explanation to clarify the
code. The updated docstring aims to be clear on how exactly the object
can be a list.
Fixes the build.
Changes proposed in this pull request:
- apply all of the isort changes that resulted from the latest version
- pin to the latest version (4.3.15) so this doesn't happen again, unless we bump the version on purpose
- 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
* 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
