Repository navigation
fix(jsonrpc): reject numeric request ids that are not long integers - #27
0xbigapple wants to merge 3 commits into
Conversation
jsonrpc4j parses integral ids beyond the long range with asInt() and fractional ids with asDouble(), so on the public endpoint a request id like 9223372036854775808 was executed and answered with id 0, and distinct ids in a batch collided. Answer an Invalid Request that echoes the original id instead. The Admin endpoint already echoed such ids unchanged; it now rejects them too so both entry points share one rule. The shared request mapper reads floating-point literals as BigDecimal so the echoed id keeps its value instead of a double approximation.
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the
 |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
Echo a rejected fractional id as the parsed double.
BigDecimal parsing throws NumberFormatException on it, which escaped the parse boundary of the Admin request handler.
What does this PR do?
JsonRpcRequestValidatorrejects numeric request ids that are not integer literals within the signed 64-bit range. Such a request is now answered with:{"jsonrpc":"2.0","error":{"code":-32600,"message":"Invalid Request: numeric id must be an integer literal within the signed 64-bit range"},"id":9223372036854775808}Why are these changes required?
jsonrpc4j's
parseId()reads such ids withasInt()orasDouble(), so the call is executed but the response carries a truncated or rounded id that the client cannot match to its request. jsonrpc4j 1.7 is the latest release andmasterstill has the same code; Rejecting is simpler than restoring the id outside jsonrpc4j, common clients send integer counters or string ids, and the JSON-RPC 2.0 specification says numeric ids SHOULD NOT contain fractional parts.This PR has been tested by:
JsonRpcServletTestandAdminJsonRpcRequestTestcover rejection with exact echo of out-of-range integers and fractional or exponent ids, in single and batch requests, and keepLong.MAX_VALUE,Long.MIN_VALUEand string ids accepted. The new assertions fail on the currentrelease_v4.8.3head.Follow up
None.
Extra details
Breaking change (release-note item): JSON-RPC requests whose numeric
idis not an integer literal within[-9223372036854775808, 9223372036854775807]are now rejected with-32600 Invalid Request.