[ https://issues.apache.org/jira/browse/SOLR-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13234114#comment-13234114 ]
David Smiley commented on SOLR-3161: ------------------------------------ Choices, choices. I should point out that qt with a leading '/' was disallowed once upon a time [and the reason was for security|https://issues.apache.org/jira/browse/SOLR-1233?focusedCommentId=13215821&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13215821]. It unfortunately came back [for no good reason (it simplified Erik's work on dataimport.jsp)|https://issues.apache.org/jira/browse/SOLR-1233], not because users didn't like this restriction. *In this light*, I think reverting to the old behavior is fine -- dataimport.jsp doesn't use qt with a leading '/' anymore, and hence the rationale for supporting a leading '/' is _gone_. To avoid breaking anyone who unwittingly depends on this in 3x, an exception can be made when the target is a SearchHandler. I repeat, nobody asked for "qt=/..." nor does anyone need it. The shards.qt parameter is not quite qt and it does need to support a leading '/' but Solr dispatches this as the path so the sharded request will never see qt=/update. But this does need protection somehow -- its actually riskier than 'qt' since it can reach out to a user-specified arbitrary server. I don't know why shards.qt exists since I don't see what could go wrong if a sharded request were to go to a path other than the original request, but I digress -- it's here. In this case, I think the SolrDispatchFilter can check if isShard=true and if so then mandate that the target handler extends SearchHandler -- which it should since only a SearchHandler has the shard logic. > 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 > > Attachments: SOLR-3161-disable-qt-by-default.patch, > 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 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-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org