-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
Do not return null if parameter is not correctly encoded #978
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
Do not return null if parameter is not correctly encoded #978
Conversation
|
play2-master-PRs #19 SUCCESS |
|
For me it just fix the #976 issue. |
|
This is not the right solution. If the URI is foo:%20bar, the %20 won't be decoded. We don't want to abort all decoding just because one illegal character exists. The reason this is failing by the way is because the colon is causing the parsing to think that the protocol is foo, and the hostname is bar. Therefore, the path is null. So it seems that new URI(path).getPath is not the right method to use for tolerant path segment decoding. What we need to solve this issue is use a path segment decoder, not something that tries to parse the string we pass in as a URI. I don't know if such a thing exists in Java, maybe we have to write our own. |
|
So, I actually found the specific part of the URI spec that we are breaking, from section 3.3:
A path segment by itself is a relative URI reference, and therefore, if the segment contains a ":", and we try to parse it as a URI, we are breaking the spec. So the simplest solution here I think is turn it into an absolute path, by prepending a /, and then dropping it after decoding. So the following should work: new URI("/" + group).getPath.drop(1) |
|
Please take a look at those commit, and particularly the last one. The fix you suggest introduces some noise in error reporting |
|
play2-master-PRs #22 SUCCESS |
|
Looks bad to me Maybe we should work on a implementation, and not a hack on ten other hack ? |
Do not return null if parameter is not correctly encoded
Squashed commit of the following: commit 171b9ad Author: Arthur Gautier <[email protected]> Date: Tue Apr 9 08:06:09 2013 +0200 Change test to new pattern commit b4c5219 Author: Arthur Gautier <[email protected]> Date: Tue Apr 9 08:05:46 2013 +0200 Add test for invalid encoded character commit 8f13cca Author: Arthur Gautier <[email protected]> Date: Tue Apr 9 07:55:10 2013 +0200 Fix as jroper suggested commit 63f298c Author: Arthur Gautier <[email protected]> Date: Mon Apr 8 22:37:02 2013 +0200 Do not return null if param is not correctly encoded commit 81e48f8 Author: Arthur Gautier <[email protected]> Date: Mon Apr 8 21:46:16 2013 +0200 non-encoded string should not return null
Squashed commit of the following: commit 171b9ad Author: Arthur Gautier <[email protected]> Date: Tue Apr 9 08:06:09 2013 +0200 Change test to new pattern commit b4c5219 Author: Arthur Gautier <[email protected]> Date: Tue Apr 9 08:05:46 2013 +0200 Add test for invalid encoded character commit 8f13cca Author: Arthur Gautier <[email protected]> Date: Tue Apr 9 07:55:10 2013 +0200 Fix as jroper suggested commit 63f298c Author: Arthur Gautier <[email protected]> Date: Mon Apr 8 22:37:02 2013 +0200 Do not return null if param is not correctly encoded commit 81e48f8 Author: Arthur Gautier <[email protected]> Date: Mon Apr 8 21:46:16 2013 +0200 non-encoded string should not return null
|
LOL |
Considering the following route
Now, let request the controller with content like:
In actual play-master, ''baz'' is not correctly encoded. ''baz'' parameter in ''bar'' action gets null.
In play <= 2.1.1, the string was passed "as-this" and not encoded in any way. This MAY break user's code, as it may receive a null parameter. This will lead to unexpected behaviour if request is miss-formated.
In this pull request I try to fallback to a safer behaviour and not to pass a null parameter to user code.