[jira] [Commented] (SOLR-11501) Depending on the parser, QParser should not parse local-params

["Yonik Seeley (JIRA)" <ji...@apache.org>]

    [ 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org