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`
Registering error handlers on the async app leads to an error on 3.0.0a5
because the error handlers are not unpacked correctly when being
registered internally.
Follow-up on #1671
Since the request context is available globally, we can remove this
complexity from the security handlers ("There should be one-- and
preferably only one --obvious way to do it.")
In addition it seems like there weren't any tests for the context in
security handler functions, and I don't think there's a lot of value in
a test for checking the context in security functions specifically.
Fixes#1682
This PR inspects the parameters of a Middleware class before passing in
the `lifespan` keyword argument. I was doubting to check the class
instead (`isinstance(LifespanMiddleware)`), but that's less flexible if
users want to write custom middleware to handle the lifespan.
This PR adds an `add_middleware` method to the apps and
`ConnexionMiddleware` to easily add middleware to the stack. Before, the
only way to do this was to pass in a complete middleware stack.
The default position to add the new middleware is right before the
`ContextMiddleware`, which is the final middleware in the stack. Another
position can be selected by passing in a `MiddlewarePosition` enum,
which defines some positions which make sense.
Since we can no longer assume that the whole middleware stack is defined
when initializing the `ConnexionMiddleware`, we need to delay building
the middleware stack until the `ConnexionMiddleware` is actually called.
This also means we need to delay registering the APIs and error
handlers. This is now all done in the `_build_middleware_stack` method.
Continues on the work of #1077 by moving the test fixtures into the
`secure_endpoint` fixture and adding a test for it in
`test_secure_api.py`.
The test will check whether an api key in the query will not lead to an
error when `strict_validation` is enabled.
Make security pluggable
- [x] Solution for standard security handlers: `security_deny`,
`security_passthrough`, `verify_none`
- [x] HTTP security handlers & overlap with basic from swagger 2
- [x] Do we need a separate handler for each `oauth2` flow?
The current implementation of replaying the stream will always replay
the first message. This PR fixes this by progressing through the
messages with each call.
Contributes to #1531
The links in security doc were pointing at an old repo and folders.
These links could be changed down the road to use relative paths since
they point to the repo internally.
This PR adds a new middleware to handle lifespan events.
I added this as a separate middleware so it is encapsulated and aligned
for both the `FlaskApp` and `AsyncApp`. It leverages a Starlette
`Router` to register and call the lifespan handler.
Fixes#1666
The `FlaskOperation` and `AsyncOperation` classes act as decorators for
their wrapped view functions, so their metadata should reflect this,
similar to what `functools.wraps` does.
This PR delays import errors for the optional Flask dependency, so you
can use the AsyncApp without Flask installed.
This issue is hidden in our tests since we install all extras. To
prevent this, we need to address
https://github.com/spec-first/connexion/issues/1389.
Changes proposed in this pull request:
- Updated the docs such that it comes with an example for passing server
arguments and serving static files
---------
Co-authored-by: Ruwann <ruwan.lambrichts@ml6.eu>
I'd like to cut an alpha release for 3.0 while we further polish the
code base and update the documentation. This way users can already test
3.0 and provide feedback.
This PR adds some very high-level documentation to serve as a starting
point for users to test the alpha version.
This PR adds a `jsonifier` argument to the app and api to align it with
other customization options. We also no longer pass it via the operation
object, which brings us closer to operations as data class only.
Fixes#942
No longer return 400 if a read-only property is provided, as discussed
in the issue. We still raise an error if write-only properties are
included in the response and response validation is enabled.
I also changed how read-/write-only works in combination with
`required`. Previously, `required` would not be overwritten by
read-/write-only. Now we just follow the spec to the letter:
- required and read-only: must be included but must be ignored by the
server
- required and write-only: impossible to achieve, but I also don't see
how this combination could make sense
- read-only: may be included but must be ignored by server
- write-only: must not be included by server
