You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "David Smiley (JIRA)" <ji...@apache.org> on 2017/11/21 22:30:00 UTC

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

     [ https://issues.apache.org/jira/browse/SOLR-11501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Smiley updated SOLR-11501:
--------------------------------
    Attachment: SOLR_11501_limit_local_params_parsing.patch

Here's an updated patch.  Not a lot changed but some.
* toggle new behavior based on luceneMatchVersion
* added CHANGES.txt upgrade notes.
* It turns out {{dismax}} is not affected because various special characters are escaped.  The QParser escapes via org.apache.solr.util.SolrPluginUtils#partialEscape.  I added a test and poked around in the debugger to feel more confident about this.
* Added tests to all parsers that use this parser in some shape or form: {{complex}}, {{dismax}}, {{edismax}} to show that by default they don't parse subqueries.  edismax can be toggled to and it's tested.  Of course {{lucene}} already has tests for this.
* as in the last patch, SolrQueryParserBase has a simple boolean allowSubQueryParsing defaulting to false.  It was not trivial to lay the groundwork to support a configurable list of parsers, and so I leave that for whatever future issue chooses to embark on that.  

I'm shooting for committing this Monday if I don't hear feedback to the contrary.

Here's the proposed CHANGES.txt:
{noformat}
Upgrade Notes
----------------------

* SOLR-11501: Starting a query string with local-params {!myparser ...} is used to switch the query parser to another,
  and is intended for use by Solr system developers, not end users doing searches.  To reduce negative side-effects of
  unintended hack-ability, we've limited the cases that local-params will be parsed to only contexts in which the
  default parser is "lucene" or "func".
  So if defType=edismax then q={!myparser ...} won't work.  In that example, put the desired query parser into defType.
  Another example is if deftype=edismax then hl.q={!myparser ...} won't work for the same reason.  In that example,
  either put the desired query parser into hl.qparser or set hl.qparser=lucene.  Most users won't run into these cases
  but some will and must change.
  If you must have full backwards compatibility, use luceneMatchVersion=7.1.0 or something earlier. (David Smiley)

* SOLR-11501: The edismax parser by default no longer allows subqueries that specify a Solr parser using either
  local-params, or the older _query_ magic field trick.  For example
  {!prefix f=myfield v=enterp}  or  _query_:"{!prefix f=myfield v=enterp}"   are not supported by default anymore.
  If you want to allow power-users to do this, set uf=*,_query_ or some other value that includes _query_.
  If you must have full backwards compatibility, use luceneMatchVersion=7.1.0 or something earlier. (David Smiley)
{noformat}

> 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_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