[
https://issues.apache.org/jira/browse/SOLR-18345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18106043#comment-18106043
]
Gus Heck commented on SOLR-18345:
---------------------------------
Is it true that after this change a local param value like
{{foo=""value-with-inadvertent-duplicate-quote"}} will now yield a value of
{{{}"value-with-inadvertent-quote{}}}?
what about {{foo=""bar="bar-forgot-a-space"}}
Does that create a value for foo of {{"bar="bar-forgot-a-space }}?
Of course all the places that need to handle quotes within values should parse
correctly, but is this appropriate for local params? will we mask errors, or
get strangeness (or even injections) when query parsers try to use values with
quotes? It feels like this might create the potential for pushing user mistakes
deeper into the code rather than handling them upfront with a parsing error.
(though I've not tested the current behavior, this is just a question)
I guess I'm wondering if supporting this questionable re-use is going to lead
us into other trouble, and whether or not there should be different encoders
for different cases. I'm asking if you already thought these cases through, not
concluding there is an actual problem yet.
> ClientUtils.encodeLocalParamVal() can produces lossy/invalid encodings
> ----------------------------------------------------------------------
>
> Key: SOLR-18345
> URL: https://issues.apache.org/jira/browse/SOLR-18345
> Project: Solr
> Issue Type: Bug
> Reporter: David Smiley
> Assignee: David Smiley
> Priority: Major
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> ClientUtils.encodeLocalParamVal(String) safely embeds an arbitrary literal
> value into a Solr local-params string (e.g. \{!key=<value>\}, for consumption
> by QueryParsing#parseLocalParams / StrParser. It had two related bugs:
> 1. It escaped an embedded single quote (') but not an embedded backslash (\).
> Since StrParser#getQuotedString treats '\' as the start of an escape
> sequence, an unescaped backslash in the value is misinterpreted on
> decode (e.g. a literal "\n" in the value becomes an actual newline).
> 2. It failed to quote a value whose first character is itself a quote
> character ('or "), even when no other quoting trigger (whitespace or '}')
> was present. QueryParsing#parseLocalParams treats a quote character
> immediately after '=' as the start of a quoted value, so such values were
> misparsed (e.g. "''" round-tripped to "").
> Both cause encoded values to not round-trip correctly, so callers building
> local-params strings from arbitrary field values/keys could produce
> corrupted or unparseable queries.
> Fix: escape backslashes in addition to single quotes, and force quoting
> whenever the value starts with a quote character.
> _(written by AI)_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
