-
Notifications
You must be signed in to change notification settings - Fork 520
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
nested-params supports multiple keys #204
base: master
Are you sure you want to change the base?
Conversation
The What's your use-case for wanting to restrict nested parameters to a particular origin? |
It's not restricting nested params to a particular origin, nested parameter parsing should be applied to data from both. The problem occurs when I want to only retrieve parameters from a particular origin. In our restful API, content can be submitted for write via the body on write requests, while on read requests query parameters can be used to filter results. They're two different sets of parameters that serve different purposes. There is a small risk that a misbehaving client includes data in both the body and query params. The query params would contaminate or override the data supplied in the body, since This all is more of a problem with Wanting to preserve the original data is a fair argument for not touching them by default, but the change introduced is opt-in behavior, by using the middleware you are consenting to have the query map manipulated as you requested anyway. |
It sounds as if your particular use case might be better served with the introduction of |
That seems a bit odd - I should branch my middleware on a per-route basis? I could do it based on the request-method, but how do I support a POST request that uses a query parameter in addition to a request body? Query params and body params aren't an either/or - http bodies are traditionally only on POST/PUT/PATCH, but any http method accepts query params. A resource is permitted to support both. I might be missing something here, what is the issue that you're seeing? Nested parameters are merely an encoding format, what problems are introduced by asking a middleware to decode a specific parameter? |
The It's possible I could expose more of the internal workings of the nested-params middleware, allowing one to write their own middleware more easily. But I don't like the idea of breaking expected behavior, even as an option. |
nested-params currently processes only the
:params
, but wrap-params also assoc's:form-params
and:query-params
onto the query map. In cases where you need to differentiate between query and body params,wrap-nested-params
will be of no use to you.This change lets you specify which keys you want to process:
It may be more proper to process all three by default, because the current behavior of
wrap-nested-params
might be unexpected. I left it at the more conservative default of just:params
for now for consistency across versions.