lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Høydahl (Commented) (JIRA) <>
Subject [jira] [Commented] (SOLR-3161) Use of 'qt' should be restricted to searching and should not start with a '/'
Date Mon, 27 Feb 2012 23:17:48 GMT


Jan Høydahl commented on SOLR-3161:

bq. !! (jaw dropping awe) Not soon enough! Apparently its when I started looking into it,
some 5+ years after Solr was released. Jan, if I submitted an optional feature to Solr, perhaps
a servlet filter that errors if parameters don't meet certain patterns, would you -1 it on

No I wouldn't. Security is very important in some environments and in fact I'd like us to
start supporting those use cases better, such as writing a generic document-level security
component for various connector frameworks (such as MCF) to hook in to. But I'm very clear
on that we should *not* start documenting ways to secure Solr/Tomcat/Jetty in a way that is
suitable for public exposure - simply because that is a slippery slope and would give users
the impression that Solr is secure and needs no further locking down. But for this issue I'm
more interested in the functionality aspect.

I must admit that the way I use {{qt}} in my projects is nothing more than a way to select
a named instance of a *Search*RequestHandler with request-param defaults. So the fact that
{{qt}} can completely switch to any RequestHandler is really too generic and seldom used.
In that context your suggestion for a {{enableQt="true"}} param could make sense. If you enable
it for all RH's, QT will work as today, or you can pick a few.
> 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
> 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