by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Federico Caselli
    @CaselIT
    yes, that's what I figured. I'm currently raising in another part of a middleware and then coping the the error data into a response and then add cookies there.
    Vytautas Liuolia
    @vytas7
    FWIW, I remember defining a custom redirect status to be able to set specific cache headers on it. Although redirects accept headers now... maybe it was for an older version of Falcon.
    Federico Caselli
    @CaselIT
    maybe it may be useful to support add_cookies on errors?
    As alternatives: have a method on the error to headers_from_response(response) or make Response._wsgi_headers public?
    Vytautas Liuolia
    @vytas7
    The discussion is not new. Some frameworks go as far as allowing to raise responses, but I'm not sure if we want to further embrace that way. See also my older comment here https://github.com/falconry/falcon/issues/1296#issuecomment-414765219 , preceding the advent of resp.complete.
    I wouldn't be opposed to adding something along the lines of Response.render_headers() though, in the spirit of Response.render_body().
    Federico Caselli
    @CaselIT
    Note: having something similar may come handy for oauth :)
    Vytautas Liuolia
    @vytas7
    Generally speaking, Falcon is focused on REST, and OAuth2 is not really a RESTful standard (not sure what to call OAut2 actually...) "design protocol". So some issues are to be expected along the way :slight_smile:
    Federico Caselli
    @CaselIT

    I wouldn't be opposed to adding something along the lines of Response.render_headers() though, in the spirit of Response.render_body().

    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

    Vytautas Liuolia
    @vytas7
    Aye, I was talking generally of render_headers, that it might make sense making this logic public for other reasons (caching?).
    Federico Caselli
    @CaselIT
    Maybe an hacky way may be to set a specific value to the headers object of the error/status to indicate to keep the resp headers?
    like, falcon.USE_RESPONSE_HEADER
    Vytautas Liuolia
    @vytas7
    Maybe it's not that bad, I think it's actually a fairly acceptable design for an own application. Maybe it's a bit more challenging to package that as a component for third party users.
    I.e. you could have specialized exceptions that are not even necessarily 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

    Federico Caselli
    @CaselIT
    Note, another alternative may be to allow middleware to indicate that a request has not succeded, similar to Response.complete
    Vytautas Liuolia
    @vytas7
    If we were to deeper invest into these things, maybe it would be best to decouple cookie logic more from Response, and provide generic functions to render the Set-Cookie header.
    Our utils are actually already quite decoupled on the other side, for cookie parsing. And especially 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 Response.complete

    As said, there is a way. To raise exceptions. :slight_smile:

    Federico Caselli
    @CaselIT

    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 Set-Cookie header.

    This is probably the best option. Maybe as a base class for status/error/response or as some functions in utils

    Vytautas Liuolia
    @vytas7
    Coming back to OAuth2. Do you really need to set advanced cookies in case of failure?
    Federico Caselli
    @CaselIT
    not really, mainly unset-cookie
    Vytautas Liuolia
    @vytas7
    Yeah that's was what I could think of :slight_smile:
    Furthermore, as I understand, for OAuth2 you would be rendering some HTML off templates to augment every OAuth step.
    And even error forms are normally presented as HTTP 200.
    Federico Caselli
    @CaselIT
    I mean, it may be useful to also use httpstatus to redirect with cookies
    Vytautas Liuolia
    @vytas7
    In that light, maybe it semantically makes sense to just render without raising?
    Or do you want users to be able to install error handlers for specialized OAuth2 exceptions?
    Federico Caselli
    @CaselIT
    no clue
    Vytautas Liuolia
    @vytas7
    I mean, it may be useful to also use httpstatus to redirect with cookies
    True dat. :arrow_up:
    Federico Caselli
    @CaselIT
    all in all the best option is probably to have a superclass to handle cookies
    Vytautas Liuolia
    @vytas7
    How would you handle HTML btw? Would you support a templating library like jinja2? Maybe OAuth2 is not really a very falconic thing :grimacing:
    Federico Caselli
    @CaselIT
    I've yet to look at it. Do you need it?
    Vytautas Liuolia
    @vytas7
    It depends on the scope of your library. But generally speaking yes, the most common OAuth2 case is redirecting you to an HTML login page, then doing a bit of a redirect circus back and forth, storing cookies along the way, and then finally redirecting you back with the oauth Bearer token or code to obtain one, either in URI fragment (for frontend / Implicit flow) or passing the code some other way.
    Federico Caselli
    @CaselIT
    a popular way is to use a cookie
    Vytautas Liuolia
    @vytas7
    A cookie is used to store authorization crentials on "your" side where the resources are stored. But that cannot be passed to an OAuth2 "client" (==third party app), due to cross-domain restrictions.
    I find these series to be a good resource on the topic: https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2
    Federico Caselli
    @CaselIT
    but alas I'm not sure if html is needed in all cases. spa would not have it I guess, also if the api is consumed by another api
    Vytautas Liuolia
    @vytas7
    (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/ ).
    Federico Caselli
    @CaselIT
    I mean it really depends on what you want to implement I guess. There are at least two main use cases:
    • want to provide login to the api with a 3rd party provider, like google/azure/etc. I don't think this needs html
    • want to be the auth server, storing users etc and authorizing them. This needs html I guess
    Vytautas Liuolia
    @vytas7
    True; I meant the latter.
    And no, just using OAuth2 from the User / Application (Client) perspective, e.g, to access Google services, you don't need all that.
    Federico Caselli
    @CaselIT

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

    I think that it has been standardized a bit more in open id connect, that builds upon oauth2, but standardizes how most things should work
    Vytautas Liuolia
    @vytas7
    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 .
    Federico Caselli
    @CaselIT

    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

    Federico Caselli
    @CaselIT

    all in all the best option is probably to have a superclass to handle cookies

    I've looked a bit at the api of Response. I'm no longer sure if this is the best option, since one could ask why add_cookie and not add_link, etc.

    Not sure how to best resolve this
    Federico Caselli
    @CaselIT
    Opened falconry/falcon#1752