lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Smiley (Commented) (JIRA)" <>
Subject [jira] [Commented] (SOLR-3161) Use of 'qt' should be restricted to searching and should not start with a '/'
Date Fri, 09 Mar 2012 19:54:59 GMT


David Smiley commented on SOLR-3161:

I think we need to come up with something for 3x soon.  I think and hope we can find broad
agreement on some things.  I think we can take a 2-3 incremental steps, starting with a better
default configuration.

I took a closer look at Erik's patch as well as some of the Solr code that makes this stuff
work.  Judging from the underlying code, if you already have a "/select" registered, then
the <requestDispatcher handleSelect="..."> setting and the notion of a default request
handler, and  "qt" is effectively unused/ignored.  "qt" is used internally still such as for
specifying a handler in query warming.  I really like this and it merely requires changes
to the example solrconfig.xml which both simplify it and secure it.  There could be a little
comment on how to get "qt" to work, if you so choose.  There is actually one other important
thing to do which is to make the admin's query UI not use the 'qt'.  I'll sign up to make
that happen.

Is anyone against (-1) me developing a simple patch doing the above and committing to 3x?
 I will of course attach the patch first for review and it would only include what I refer
to in this JIRA comment.

Subsequent to the above, I'm still concerned that someone's existing configuration is susceptible
to /select?qt=/update. IMO if the path is /select, then qt should not start with a leading
'/', thereby safeguarding people's existing default configuration.  If you are -1 to my opinion,
speak up.
> Use of 'qt' should be restricted to searching and should not start with a '/'
> -----------------------------------------------------------------------------
>                 Key: SOLR-3161
>                 URL:
>             Project: Solr
>          Issue Type: Improvement
>          Components: search, web gui
>            Reporter: David Smiley
>            Assignee: David Smiley
>             Fix For: 3.6, 4.0
>         Attachments: SOLR-3161-dispatching-request-handler.patch, SOLR-3161-dispatching-request-handler.patch
> I haven't yet looked at the code involved for suggestions here; I'm speaking based on
how I think things should work and not work, based on intuitiveness and security. In general
I feel it is best practice to use '/' leading request handler names and not use "qt", but
I don't hate it enough when used in limited (search-only) circumstances to propose its demise.
But if someone proposes its deprecation that then I am +1 for that.
> Here is my proposal:
> Solr should error if the parameter "qt" is supplied with a leading '/'. (trunk only)
> Solr should only honor "qt" if the target request handler extends solr.SearchHandler.
> The new admin UI should only use 'qt' when it has to. For the query screen, it could
present a little pop-up menu of handlers to choose from, including "/select?qt=mycustom" for
handlers that aren't named with a leading '/'. This choice should be positioned at the top.
> And before I forget, me or someone should investigate if there are any similar security
problems with the shards.qt parameter. Perhaps shards.qt can abide by the same rules outlined
> Does anyone foresee any problems with this proposal?
> On a related subject, I think the notion of a default request handler is bad - the default="true"
thing. Honestly I'm not sure what it does, since I noticed Solr trunk redirects '/solr/' to
the new admin UI at '/solr/#/'. Assuming it doesn't do anything useful anymore, I think it
would be clearer to use <requestHandler name="/select" class="solr.SearchHandler"> instead
of what's there now. The delta is to put the leading '/' on this request handler name, and
remove the "default" attribute.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message