lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Hatcher (Issue Comment Edited) (JIRA)" <j...@apache.org>
Subject [jira] [Issue Comment Edited] (SOLR-3161) Use of 'qt' should be restricted to searching and should not start with a '/'
Date Tue, 28 Feb 2012 17:07:46 GMT

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

Erik Hatcher edited comment on SOLR-3161 at 2/28/12 5:06 PM:
-------------------------------------------------------------

I just attached a patch as an example along the lines of what Hoss proposed.  I removed default="true",
renamed "search" to "/select", and set handleSelect="false".  Then I added some request handlers:

  * lazy - a lazy loaded search request handler
  * notlazy - a concrete (not lazy loaded) search request handler
  * /dispatch - a DispatchingRequestHandler that uses qt to look up a non-lazy loaded *SearchRequestHandler*
and dispatches to that
  * /handlers - just a quick/easy way for me to see the defined request handlers (using the
handlers.vm) template

Here are some requests and their effect:

http://localhost:8983/solr/handlers
{code}
 - [/admin/plugins]  - org.apache.solr.handler.admin.PluginInfoHandler@428d5aad
 - [/admin/system]  - org.apache.solr.handler.admin.SystemInfoHandler@4e3c35fd
 - [notlazy]  - org.apache.solr.handler.component.SearchHandler@52fc9d2b
 - [/admin/file]  - org.apache.solr.handler.admin.ShowFileRequestHandler@46b29c9d
 - [/dispatch]  - org.apache.solr.handler.component.DispatchingRequestHandler@78482bad
 - [/admin/luke]  - org.apache.solr.handler.admin.LukeRequestHandler@4a2ba88c
 - [/update/javabin]  - org.apache.solr.handler.BinaryUpdateRequestHandler@7846a55e
 - [/update]  - org.apache.solr.handler.XmlUpdateRequestHandler@6612fc02
 - [/terms]  - org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper@685f1ba8
 - [/admin/threads]  - org.apache.solr.handler.admin.ThreadDumpHandler@3c10e820
 - [/replication]  - org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper@79f7abae
 - [/analysis/field]  - org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper@73286b10
 - [lazy]  - org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper@628d2280
 - [/browse]  - org.apache.solr.handler.component.SearchHandler@50c7833c
 - [/admin/ping]  - org.apache.solr.handler.PingRequestHandler@3e5646a5
 - [/analysis/document]  - org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper@5da5e65f
 - [/select]  - org.apache.solr.handler.component.SearchHandler@36b79701
 - [/admin/mbeans]  - org.apache.solr.handler.admin.SolrInfoMBeanHandler@4f1adeb7
 - [/update/csv]  - org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper@6d13e8f3
 - [/handlers]  - org.apache.solr.handler.DumpRequestHandler@3622e177
 - [/elevate]  - org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper@2c006765
 - [/update/xslt]  - org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper@4e842e74
 - [/update/json]  - org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper@4805e9f1
 - [/get]  - org.apache.solr.handler.RealTimeGetHandler@7c41f227
 - [/update/extract]  - org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper@4d811e2c
 - [/admin/properties]  - org.apache.solr.handler.admin.PropertiesRequestHandler@57e40274
 - [tvrh]  - org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper@3a5d3ac0
 - [/spell]  - org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper@3ebc312f
 - [/debug/dump]  - org.apache.solr.handler.DumpRequestHandler@354124d6
{code}

http://localhost:8983/solr/select?q=*:*
  - returns our tried and true Solr response

http://localhost:8983/solr/dispatch?q=*:*&qt=lazy
  - returns HTTP 400 with "Must be a SearchHandler: lazy"

http://localhost:8983/solr/dispatch?q=*:*&qt=notlazy
  - returns HTTP 200 using the "notlazy" request handler's response

And of course you can with this patch, but maybe that's silly to allow, do this request http://localhost:8983/solr/dispatch?q=*:*&qt=/select
  - which dispatches to /select, basically the same as http://localhost:8983/solr/select?q=*:*

I personally really like the idea of qt not being special at all, yet if you do want to use
something like that that you wire in a DispatchingRequestHandler.  In fact, I'll go so far
as to say that Solr's main dispatching filter shouldn't use any query string parameters, and
only request handlers themselves use them.  (that begs the question about wt, but there's
HTTP mechanisms for specifying the format you desire a "resource" in :).  I'll digress on
that last point.  The gist here is that with some simple config tweaks and a dispatcher, you
can have your cake and eat it too.
                
      was (Author: ehatcher):
    I just attached a patch as an example along the lines of what Hoss proposed.  I removed
default="true", renamed "search" to "/select", and set handleSelect="false".  Then I added
some request handlers:

  * lazy - a lazy loaded search request handler
  * notlazy - a concrete (not lazy loaded) search request handler
  * /dispatch - a DispatchingRequestHandler that uses qt to look up a non-lazy loaded *SearchRequestHandler*
and dispatches to that
  * /handlers - just a quick/easy way for me to see the defined request handlers (using the
handlers.vm) template

Here are some requests and their effect:

http://localhost:8983/solr/handlers
{code}
 - [/admin/plugins]  - org.apache.solr.handler.admin.PluginInfoHandler@428d5aad
 - [/admin/system]  - org.apache.solr.handler.admin.SystemInfoHandler@4e3c35fd
 - [notlazy]  - org.apache.solr.handler.component.SearchHandler@52fc9d2b
 - [/admin/file]  - org.apache.solr.handler.admin.ShowFileRequestHandler@46b29c9d
 - [/dispatch]  - org.apache.solr.handler.component.DispatchingRequestHandler@78482bad
 - [/admin/luke]  - org.apache.solr.handler.admin.LukeRequestHandler@4a2ba88c
 - [/update/javabin]  - org.apache.solr.handler.BinaryUpdateRequestHandler@7846a55e
 - [/update]  - org.apache.solr.handler.XmlUpdateRequestHandler@6612fc02
 - [/terms]  - org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper@685f1ba8
 - [/admin/threads]  - org.apache.solr.handler.admin.ThreadDumpHandler@3c10e820
 - [/replication]  - org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper@79f7abae
 - [/analysis/field]  - org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper@73286b10
 - [lazy]  - org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper@628d2280
 - [/browse]  - org.apache.solr.handler.component.SearchHandler@50c7833c
 - [/admin/ping]  - org.apache.solr.handler.PingRequestHandler@3e5646a5
 - [/analysis/document]  - org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper@5da5e65f
 - [/select]  - org.apache.solr.handler.component.SearchHandler@36b79701
 - [/admin/mbeans]  - org.apache.solr.handler.admin.SolrInfoMBeanHandler@4f1adeb7
 - [/update/csv]  - org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper@6d13e8f3
 - [/handlers]  - org.apache.solr.handler.DumpRequestHandler@3622e177
 - [/elevate]  - org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper@2c006765
 - [/update/xslt]  - org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper@4e842e74
 - [/update/json]  - org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper@4805e9f1
 - [/get]  - org.apache.solr.handler.RealTimeGetHandler@7c41f227
 - [/update/extract]  - org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper@4d811e2c
 - [/admin/properties]  - org.apache.solr.handler.admin.PropertiesRequestHandler@57e40274
 - [tvrh]  - org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper@3a5d3ac0
 - [/spell]  - org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper@3ebc312f
 - [/debug/dump]  - org.apache.solr.handler.DumpRequestHandler@354124d6
{code}

http://localhost:8983/solr/select?q=*:*
  - returns our tried and true Solr response

http://localhost:8983/solr/dispatch?q=*:*&qt=lazy
  - returns HTTP 400 with "Must be a SearchHandler: lazy"

http://localhost:8983/solr/dispatch?q=*:*&qt=notlazy
  - returns HTTP 200 using the "notlazy" request handler's response

And of course you can with this patch, but maybe that's a silly to allow, do this request
http://localhost:8983/solr/dispatch?q=*:*&qt=/select
  - which dispatches to /select, basically the same as http://localhost:8983/solr/select?q=*:*

I personally really like the idea of qt not being special at all, yet if you do want to use
something like that that you wire in a DispatchingRequestHandler.  In fact, I'll go so far
as to say that Solr's main dispatching filter shouldn't use any query string parameters, and
only request handlers themselves use them.  (that begs the question about wt, but there's
HTTP mechanisms for specifying the format you desire a "resource" in :).  I'll digress on
that last point.  The gist here is that with some simple config tweaks and a dispatcher, you
can have your cake and eat it too.
                  
> 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-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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message