[
https://issues.apache.org/jira/browse/SOLR-11501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16217034#comment-16217034
]
Yonik Seeley commented on SOLR-11501:
-------------------------------------
I think it would be useful for people to be able to control this even for the
lucene qparser.
Something to consider... what about a specification of what parsers are
allowed/disallowed?
{code}{!lucene qparsers=query,func,join}...
{!lucene qparsers=*,-join,-graph}...
{!lucene qparsers=}... // no sub-qparsers allowed
{code}
We could even make this do double-duty... be able to turn off lucene parser
builtins as well (fuzzy queries, etc?)
For dismax, it seems like bug this ever parsed/used local params, the escaping
should be enhanced so this doesn't happen.
Both dismax and edismax need to not throw exceptions when encountering
localParams as well.
As far as this patch... I don't know at this point in time. It's hard to
figure out what might break or what behavior is undesirable. Need to look at
all of the places that use a defType other than lucene and func.
Why not do it the other way: disable for dismax, optionally disable for
extended. That would seem to make it much easier to reason about.
> Depending on the parser, QParser should not parse local-params
> --------------------------------------------------------------
>
> Key: SOLR-11501
> URL: https://issues.apache.org/jira/browse/SOLR-11501
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
> Reporter: David Smiley
> Assignee: David Smiley
> Attachments: SOLR_11501_limit_local_params_parsing.patch
>
>
> Solr should not parse local-params (and thus be able to switch the query
> parser) in certain circumstances. _Perhaps_ it is when the QParser.getParser
> is passed "lucene" for the {{defaultParser}}? This particular approach is
> just a straw-man; I suspect certain valid embedded queries could no longer
> work if this is done incorrectly. Whatever the solution, I don't think we
> should assume 'q' is special, as it's valid and useful to build up queries
> containing user input in other ways, e.g. {{q= +field:value +\{!dismax
> v=$qq\}&qq=user input}} and we want to protect the user input there
> similarly from unwelcome query parsing switching.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
