I wouldn't be opposed to adding something along the lines of
Response.render_headers()though, in the spirit of
it's a bit strange logically though. Since we whould: set headers on resp -> copy headers on error -> override resp.headers with headers from error
HTTPErrors, and then just do the right thing in the corresponding error handler.
But, at the same time
Maybe it's a bit more challenging to package that as a component for third party users
structures.ETag(not related to cookies, but another header thing).
Note, another alternative may be to allow middleware to indicate that a request has not succeded, similar to
As said, there is a way. To raise exceptions. :slight_smile:
If we were to deeper invest to into these things, maybe it would be best to decouple cookie logic more from
Response, and provide generic functions to render the
This is probably the best option. Maybe as a base class for status/error/response or as some functions in utils
Bearertoken or code to obtain one, either in URI fragment (for frontend / Implicit flow) or passing the code some other way.
(Just a note regarding Implicit, it's no longer the latest fashion for FE either, see, for instance, here: https://espressocoder.com/2019/10/28/secure-your-spa-with-authorization-code-flow-with-pkce/ ).
BTW I've also seen post requests for the redirect of the redirection flow.
Generally speaking, full OAuth2 & OIDC are indeed heavy beasts to support. Maybe the first iteration could just address a couple of concrete use cases, instead of trying cover everything a-la https://authlib.org .
I believe that for the server you can leverage a lot from authlib. The integration for flask and django are not too large