Skip to content

fix: Validate the log_level severity and partition parameters - #7922

Closed
SoubeDev wants to merge 2 commits into
XRPLF:developfrom
SoubeDev:fix-loglevel-param-type-validation
Closed

fix: Validate the log_level severity and partition parameters#7922
SoubeDev wants to merge 2 commits into
XRPLF:developfrom
SoubeDev:fix-loglevel-param-type-validation

Conversation

@SoubeDev

Copy link
Copy Markdown

doLogLevel read both parameters with an unguarded asString(), which throws for arrays and objects and silently stringifies every scalar. The throw was swallowed by callMethod's catch-all, so a malformed value produced a generic internal error rather than invalidParams, and the request was recorded as a server fault in the perf log.

The severity path was only half broken: a coerced scalar still failed Logs::fromString and came back as invalidParams, so just arrays and objects misbehaved. The partition path had no downstream validation at all, and Logs::get creates a sink on demand, so a coerced value permanently added a partition named "42", "true" or "" to the map that log_level itself then reported on every subsequent call.

Guard both conversions with an isString() check and return invalidParams when it fails. Reject the empty partition name for the same reason the type check exists: it is not a partition anyone can have meant, and accepting it wedges a nameless sink into the listing forever.

This makes the handler stricter: a severity or partition given as a number, a bool, or null was previously coerced and is now rejected. The commandline builds both fields from argv via asString(), so they are always strings there and the parser is unaffected.

Also drop the second isMember(partition) test, which was unconditionally true because the preceding branch already returned, along with the unreachable return it guarded. No behavior change.

Add a LogLevel test suite, which did not exist; the RPCCall cases cover only the commandline-to-JSON parse and never reach the handler.

High Level Overview of Change

Context of Change

API Impact

  • Public API: New feature (new methods and/or new fields)
  • Public API: Breaking change (in general, breaking changes should only impact the next api_version)
  • libxrpl change (any change that may affect libxrpl or dependents of libxrpl)
  • Peer protocol change (must be backward compatible or bump the peer protocol version)

SoubeDev and others added 2 commits July 31, 2026 12:01
doLogLevel read both parameters with an unguarded asString(), which throws
for arrays and objects and silently stringifies every scalar. The throw was
swallowed by callMethod's catch-all, so a malformed value produced a generic
internal error rather than invalidParams, and the request was recorded as a
server fault in the perf log.

The severity path was only half broken: a coerced scalar still failed
Logs::fromString and came back as invalidParams, so just arrays and objects
misbehaved. The partition path had no downstream validation at all, and
Logs::get creates a sink on demand, so a coerced value permanently added a
partition named "42", "true" or "" to the map that log_level itself then
reported on every subsequent call.

Guard both conversions with an isString() check and return invalidParams when
it fails. Reject the empty partition name for the same reason the type check
exists: it is not a partition anyone can have meant, and accepting it wedges a
nameless sink into the listing forever.

This makes the handler stricter: a severity or partition given as a number, a
bool, or null was previously coerced and is now rejected. The commandline
builds both fields from argv via asString(), so they are always strings there
and the parser is unaffected.

Also drop the second isMember(partition) test, which was unconditionally true
because the preceding branch already returned, along with the unreachable
return it guarded. No behavior change.

Add a LogLevel test suite, which did not exist; the RPCCall cases cover only
the commandline-to-JSON parse and never reach the handler.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The entry was added with a placeholder because the pull request did not
exist when the fix was committed. Point it at XRPLF#7922.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@SoubeDev SoubeDev closed this Jul 31, 2026
@SoubeDev
SoubeDev deleted the fix-loglevel-param-type-validation branch July 31, 2026 16:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant