APIv2(account_info): handle invalid "signer_lists" value #4585
Conversation
| // assigning any string value works. Do not allow this | ||
| // This for api v2 onwards |
There was a problem hiding this comment.
The tiniest of nits: The comment says "... allow this This for ...". Consider removing the capitalized "This".
| // The document states that signer_lists is a bool, however | ||
| // assigning any string value works. Do not allow this | ||
| // This for api v2 onwards | ||
| if (!params[jss::signer_lists].isBool() && context.apiVersion > 1) |
There was a problem hiding this comment.
do we need to check the context.apiVersion here? We assume that all the validators are running the latest version of the rippled codebase. Otherwise, the laggards will be incompatible with the rest of the network right?
There was a problem hiding this comment.
This is a situation where we don't need to worry about validators very much, at least on the main net. This is an RPC query. It's not typical for main net validators to be required also handle very many RPC queries.
The context.api can be a value passed in by the caller as shown in the test where it says "\"api_version\": 2. So, yes, we should check the api_version. It can be different from one RPC call to the next.
There was a problem hiding this comment.
i see okay, thanks for the clarification 👍
I'm guessing the version of rippled software is preserved in a different variable right?
There was a problem hiding this comment.
Yes, the software version (e.g., 1.12.0-b1) is elsewhere. The code never needs to check the software version because it is compiled into the binary with whatever software version it has. The api_version is a different kind of beast.
| @@ -127,7 +127,7 @@ doAccountInfo(RPC::JsonContext& context) | |||
|
|
|||
| // The document states that signer_lists is a bool, however | |||
| // assigning any string value works. Do not allow this | |||
| // This for api v2 onwards | |||
| // this for api v2 onwards | |||
There was a problem hiding this comment.
😄 Close. If you read the sentence, it now reads "... allow this this for ...". The word "this" appears two times in a row. Now that neither of the instances of "this" are capitalized feel free to remove either one.
There was a problem hiding this comment.
oops, I meant to write "this is for api v2 onwards". I just updated the comment for more clarity. Hope the updated one is fine 😄
When requesting `account_info` with an invalid `signer_lists` value, the API should return an "invalidParams" error. `signer_lists` should have a value of type boolean. If it is not a boolean, then it is invalid input. The response now indicates that. * This is an API breaking change, so the change is only reflected for requests containing `"api_version": 2` * Fix XRPLF#4539
intelliot
changed the title
When requesting `account_info` with an invalid `signer_lists` value, the API should return an "invalidParams" error. `signer_lists` should have a value of type boolean. If it is not a boolean, then it is invalid input. The response now indicates that. * This is an API breaking change, so the change is only reflected for requests containing `"api_version": 2` * Fix XRPLF#4539
When requesting `account_info` with an invalid `signer_lists` value, the API should return an "invalidParams" error. `signer_lists` should have a value of type boolean. If it is not a boolean, then it is invalid input. The response now indicates that. * This is an API breaking change, so the change is only reflected for requests containing `"api_version": 2` * Fix XRPLF#4539
High Level Overview of Change
Signer_list with invalid input should have error'ed out. Fixed this issue in this PR. (fix for issue #4539)
Context of Change
For API version 2, if signer_list has a value not of type boolean, it will return invalidParam error
Type of Change
Refer to Github link above.
Added own unit test to test for signer_list in API v2