[ https://issues.apache.org/jira/browse/SOLR-11501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16830248#comment-16830248 ]
Fredrik Rodland commented on SOLR-11501: ---------------------------------------- Has this broken pther use of \{!<tag|parent>} for the q-parameter? Or am I missing something. I also asked more or less the same question on the mailling list btw: [http://lucene.472066.n3.nabble.com/Unable-to-tag-queries-q-in-SOLR-gt-7-2-td4433617.html] > 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 > Priority: Major > Fix For: 7.2 > > 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 (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org