lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-3161) Use of 'qt' should be restricted to searching and should not start with a '/'
Date Mon, 27 Feb 2012 18:48:46 GMT

    [ https://issues.apache.org/jira/browse/SOLR-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13217382#comment-13217382
] 

Hoss Man commented on SOLR-3161:
--------------------------------

-0

1) there are plenty of people who are happily using "qt" to dynamicly pick their request handler
who don't care about securing their solr instances -- we shouldn't break things for them if
we can avoid it.

2) assuming qt should be allowed only if it is an instance of solr.SearchHandler seems narrow
minded to me -- it puts a totally arbitrary limitation on the ability for people to have their
own request handlers that are treated as "first class citizens" and seems just as likely to
lead to suprise and frustration as it is to appreciation for the "safety" of the feature (not
to mention it procludes perfectly safe "query" type handlers like MLTHnadler and AnalysisRequestHandler


if he root goal is "make solr safer for people who don't want/expect "qt" based requests then
unless i'm overlooking something it seems like there is a far simpler and more straightforward
solution...

a) change the example solrocnfig to use handleSelect="false"
b) remove the (long ago deprecated) SolrServlet

if handleSelect == false, then the request dispatcher won't look at "/select" requests at
all (unless someone has a handler named "/select") and it would do dispatching based on the
"qt" param.  currently if that's false the logic falls throough to the SolrServlet, but if
that's been removed then the request will just fail.

So new users who copy the example will have only path based request handlers by default, and
will have to go out of their way to set handleSelect=true to get qt based dispatching.

Bonus points: someone can write a DispatchingRequestHandler that can optionally be configured
with some name (such as "/select") and does nothing put look for a "qt" param and forward
to the handler with that name -- but it can have configuration options indicating which names
are permitted (and any other names would be rejected)

...on the whole, compared to the original suggestion in this issue, that seems a lot safer
for people who want safety, and a lot simpler to document.

comments? 

                
> Use of 'qt' should be restricted to searching and should not start with a '/'
> -----------------------------------------------------------------------------
>
>                 Key: SOLR-3161
>                 URL: https://issues.apache.org/jira/browse/SOLR-3161
>             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
above.
> 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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message