Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support passing resource context to downstream ring handlers #99

Closed
silasdavis opened this issue Feb 1, 2014 · 0 comments
Closed

Support passing resource context to downstream ring handlers #99

silasdavis opened this issue Feb 1, 2014 · 0 comments

Comments

@silasdavis
Copy link
Contributor

I have an authorization function I run in :authorized? from which I get back a token. I need to log this token along side the eventual status code of the final request. When I get the token in :authorized the status the has not yet been determined - I need to wait until a handler is called. However, I need to log all requests regardless of their handler. I don't want to repeat myself in every handler

My first thought was to try and pass my :auth-token to a downstream ring handler (at which point I will know the status code) by setting it in the context, but by default as-response does not pass any of the context into the response map.

I could use my own as-response via reify or otherwise, but I would still need to use this in every single :handle-* functions which is ugly and repetitive and I might as well just log it there.

I could extend-protocol of liberator.representation/Representation in my module over String to override as-response, but I think extend-protocol is meant to be global and the load order would matter which is ugly.

Something like a :handle-finally function would allow me to do what I want without having to explicitly specify handlers for all status codes, but it seems there may be a broader problem that there is no easy way to 'break out' information from the liberator resource context out to ring middlewares, which seems like the right thing to do in some contexts. The obvious way to solve it would be to treat a :response map in the context as containing key-value pairs to override the response created by liberator. This may also be useful when it is necessary to bend liberators rules, for example when needing to provide a 302 redirect. It also seems in the spirit of composable middlewares. Currently liberator is a bit of a black box with respect to ring.

Thoughts?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants