I'm starting to use the project with the newly release 3 version.
70084bcc4c/docs/middleware.rst (L115-L120)
It seems this example is not correct.
1. missing import for SecurityMiddleware
2. `ConnexionMiddleware.default_middlewares` is a list of classes, not
class instances: the filtering never happen.
Fixes#1787
In the `FlaskApp`, the error handlers were still registered on the
underlying Flask app instead of on the `ExceptionMiddleware`, which led
to them not following the documented behavior.
The documentation was also incorrect about ignoring error handlers
registered on the flask application. We are only ignoring the default
error handlers registered by Flask itself.
This is a breaking change, however, since this functionality was not
following the documented behavior, and 3.0.0 was only recently released,
I propose to release this as a patch version.
Tested with `swagger-ui-bundle==1.1.0` from Test PyPI.
Opening this as a draft PR, since I didn't publish `swagger-ui-bundle`
to the main PyPI yet, which I would like to do shortly before we release
Connexion 3.
Before Connexion 2.8, the `swagger_ui_bundle` version didn't have an
upper bound. So if anyone runs into any issues because of this update,
I'd rather have them come look for answers when Connexion 3 is out.
Fixes#1152.
Currently, when a request body is empty, the JSON request validator
would parse it into None, which is later passed down to the JSON Schema
validator. However, jsonschema's validation error message for this case
(when nullable is false) "None is not of type 'object'" is not
particularly friendly to either the API user, nor the website developer.
This change adds a specific check before the None value is passed to
jsonschema to emit a better error message directly.
I also added some drive-by improvements on function argument typing
since _validate in validators don't seem to expect receiving None, but
_parse (the result of which is passed to _validate) is totally allowed
to return None (or anything really). This does not seem to reflect the
logic well.
I’m not exactly sure if this is the best way to do this in Connexion
3.x. [We do have a patch in Connexion 2.x to achieve a similar
effect](e89a7eeea6)
so if anyone understands how the two implementations correspond please
tell me whether the two do the same thing 🙂
---------
Co-authored-by: Robbe Sneyders <robbe.sneyders@ml6.eu>
This PR adds a copyright notice for the new authors / maintainers of
connexion. It also reformats the license / notice files as prescribed by
the license.
I was writing the documentation on exception handling, and I noticed
that it was very hard to explain our current behavior.
Error handlers can be registered either on the internal Flask app (not
the Starlette one) or on the Connexion app, which leads to some
undefined (actually just really hard to explain) behavior. Eg.
- Registering error handlers on a status code would capture
`starlette.HTTPException` errors on the Connexion app, and
`werkzeug.HTTPException` errors on the Flask App, which means that
registering an error handler on a status code doesn't catch all the
errors with that status code.
- Flask does some default error handling which leads to some exceptions
never reaching the error handlers registered on the Connexion app.
So I made the following changes:
- Replaced the default error handlers we registered on the Flask app
with a default handler on the `ExceptionMiddleware` that takes into
account other handlers registered on status codes.
- Configured Flask to propagate exceptions instead of catching them.
- Abstracted away the Starlette `Request` and `Response` types, so users
can and must now use `ConnexionRequest`
and `ConnexionResponse` types in error handlers.
- Renamed the `ASGIRequest` class to `ConnexionRequest` since it is the
only Request class part of the high level
Connexion interface.
We could also rename `ConnexionRequest` and `ConnexionResponse` to just
`Request` and `Response`. Wdyt?
Python 3.7 is end of life. We should support the newer versions instead.
I also changed tox to only run against the minimum dependency versions
on the lowest Python version, since this should lead to the lowest
versions over all Python versions, and hopefully helps speed up our
pipelines :)
Fixes#1689
Changes proposed in this pull request:
- Pass through request body in case of `GET` and `DELETE` requests
---------
Co-authored-by: Robbe Sneyders <robbe.sneyders@gmail.com>
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 :)
Follow-up on #1708
([comment](https://github.com/spec-first/connexion/pull/1708#issuecomment-1581196226))
As mentioned there, there is a `__repr__` but not a `__str__`, leading
to an empty log message (for HTTPExceptions).
An example when running the dev server (previously the first line would
just be an empty line):
```
HTTPException(status_code=404, detail='Not Found')
INFO: 127.0.0.1:33538 - "GET /swaggers/ui/ HTTP/1.1" 404 Not Found
```
However, I would also be fine with just removing the logging here as
`HTTPException`s can be part of the normal flow, without indicating an
actual application error (case in point: raising a `Not Found`
exception)
When an internal server error
occurs, the logged error is not really useful for the user.
For example, a `KeyError` will only print the missing key instead of the
full stacktrace and error.
Adding it to the common error handler as that one is meant to catch all
remaining errors, `HTTPException`s are handled by another error handler.
Fixes # .
I want to use connexion with newer Starlette
Changes proposed in this pull request:
- Loosen requirements on starlette version
---------
Co-authored-by: Robbe Sneyders <robbe.sneyders@ml6.eu>
Fixes#1697
Because of a wrong comparison against the position `Enum`, middleware
was not actually being added to the stack via `add_middleware`. This PR
fixes this, adds a warning when the middleware position cannot be found,
and adds a test.
Fixes the `Nonetype: None` issue that shows up in the logging.
It is caused by using `logging.exception` while not in an exception
handler.
I don't know whether including the full traceback makes sense in the
logging, but that could also be possible by adding `exc_info=exc`
