Vertx-web: No distinction between Query and Path params

Created on 3 Feb 2016  路  7Comments  路  Source: vert-x3/vertx-web

Hi,

There is no distinction between a query param and a path param in the requestContext.params() method or the requestContext.getParam('name') call.

If there is no guarantee that the param comes from the path, then a request could be constructed to overwrite the path param with a query param.

e.g. http://some.host.com/:name can be called with
http://some.host.com/fred?name=george causing a possible security issue

Most helpful comment

I don't consider this a bug, either a choice or a missing feature, but I do agree it'd be a nice improvement. Many frameworks provide this distinction (think of JAX-RS @QueryParam vs. @PathParam or Spring MVC @PathVariable vs. @RequestParam).

Security aside, I prefer this approach for code readability. Sometimes the code handling the parameter is not close to the route declaration, and thus getParam can be misleading for the reader (if the route is declared 3 lines above, no problem obviously). So 馃憤 for me.

All 7 comments

@plenderyou path params are a not official "parameters" in the sense that they are not part of the HTTP query string, so in vert.x-web as in many other frameworks they are just masked as being part of the query string.

Once you use both query string and path params with the same name you will end up with a unordered list with all results for example in your case: [fred, george].

If you want to be sure there's only 1 value then you should use rc.request.params.getAll('name') and work with the list. If you just use get('name') then you only get the last added value which is the path one (query processing happens before path when filling the variable).

Ok, I understand.

When writing REST services path params are often used, I guess I'll just have to filter out the query params in code to ensure no-one is trying to circumvent the call by overriding the parameter.

I do think this is a security issue though and since vertx-web supports the concept of path params it should provide an easy way to distinguish between the 2 types.

Agreed, a way to make the distinction would be welcomed.

I'm considering this a bug. Please make this behavior configurable and have a second map with the path parameters.
For queries where callers can use any valid parameter name, this leads to unexpected problems.

@beders it is not a bug since it was never documented or said that is was supposed to behave like that. It is in fact a new feature that should be implemented. Of course if this is too critical for you you're always welcome to submit a PR since the vert.x team is very busy with many features and this one has a low priority for now.

I don't consider this a bug, either a choice or a missing feature, but I do agree it'd be a nice improvement. Many frameworks provide this distinction (think of JAX-RS @QueryParam vs. @PathParam or Spring MVC @PathVariable vs. @RequestParam).

Security aside, I prefer this approach for code readability. Sometimes the code handling the parameter is not close to the route declaration, and thus getParam can be misleading for the reader (if the route is declared 3 lines above, no problem obviously). So 馃憤 for me.

Fixed by #363

Was this page helpful?
0 / 5 - 0 ratings