You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by sam ” <sk...@gmail.com> on 2012/04/10 17:46:00 UTC
custom query string parsing?
I would like to transform the following:
/myhandler/?colors=red&colors=blue&materials=leather
to a Query that is similar to:
/select/?fq:colors:(red OR
blue)&fq:materials:leather&facet=on&facet.field=.... and various default
query params.
I tried to do this by providing QParserPlugin:
<queryParser name="myQueryParser" class="my.QueryParserPlugin"/>
<requestHandler name="/myhandler" class="solr.SearchHandler">
<lst name="defaults">
<!-- various default params -->
<str name="defType">myQueryParser</str>
</lst>
</requestHandler>
In my.QueryParser (returned by my.QueryParserPlugin) I can:
getReq().getParamString();
and parse that string to get non-default SolrParams.
And, build a Query object to my liking.
Am I going about the right direction? It'd be much easier if I could place
a custom app proxying solr... But, I am required to expose solr to the
public without middle layer between the browsers and solr.
So, my idea is to reject all solr query params but handful of custom params
such as colors, materials, .. and build a Query object myself combining
with default SolrParams specified in solrconfig.xml .
Is this feasible? I don't really like to parse query string myself
(returned by getReq().getParamString()) ..
getReq().getParams() returns DefaultSolrParams, which does provide a way
to get non-default params only.
Re: custom query string parsing?
Posted by Chris Hostetter <ho...@fucit.org>.
: Only /solr/mycore/select/?qt=/update uses update handler :P
or just register your handler using the name "/select" then the request
dispatcher will use it, and ignore "qt".
In trunk, the legacy SolrServlet has been removed, so you'll be able to
set handleSelect="false" on the <requestDispatcher /> and not worry about
/select at all unless you really want a url with that path to exist.
-Hoss
Re: custom query string parsing?
Posted by sam ” <sk...@gmail.com>.
Actually, /solr/mycore/myhandler/?qt=/update still uses my handler.
Only /solr/mycore/select/?qt=/update uses update handler :P
On Wed, Apr 11, 2012 at 11:41 AM, sam ” <sk...@gmail.com> wrote:
> Yah, RequestHandler is much better. Thanks! I don't know why I started
> with QParserPlugin and SearchComponent.
>
>
> Even with my own RequestHandler that only passes down selected query
> params, people can still get around it through qt parameter:
>
> ?qt=/update&stream.update=<delete><query>*:*</query></delete>&commit=true
>
> I think I am trying to solve two things at once: security and application
> specific query parameter transformation.
>
> Security will have to be handled elsewhere. Query parameter manipulation
> can indeed be done by providing RequestHandler...
> If I could just introduce a custom application, both will be solved quite
> easily.
> But, I am required to do all application development using Solr only
> (through plugins and velocity templates).
>
>
> Thanks.
>
>
>
> On Tue, Apr 10, 2012 at 10:19 PM, Chris Hostetter <
> hossman_lucene@fucit.org> wrote:
>
>>
>> : Essentially, this is what I want to do (I'm extending SearchComponent):
>>
>> the level of request manipulation you seem to be interested strikes me as
>> something that you should do as a custom RequestHandler -- not a
>> SearchComponent or a QParserPlugin.
>>
>> You can always subclass SearchHandler, and override the handleRequest
>> method to manipulate the request however you want and then delegate to
>> super.
>>
>>
>> -Hoss
>>
>
>
Re: custom query string parsing?
Posted by sam ” <sk...@gmail.com>.
Yah, RequestHandler is much better. Thanks! I don't know why I started with
QParserPlugin and SearchComponent.
Even with my own RequestHandler that only passes down selected query
params, people can still get around it through qt parameter:
?qt=/update&stream.update=<delete><query>*:*</query></delete>&commit=true
I think I am trying to solve two things at once: security and application
specific query parameter transformation.
Security will have to be handled elsewhere. Query parameter manipulation
can indeed be done by providing RequestHandler...
If I could just introduce a custom application, both will be solved quite
easily.
But, I am required to do all application development using Solr only
(through plugins and velocity templates).
Thanks.
On Tue, Apr 10, 2012 at 10:19 PM, Chris Hostetter
<ho...@fucit.org>wrote:
>
> : Essentially, this is what I want to do (I'm extending SearchComponent):
>
> the level of request manipulation you seem to be interested strikes me as
> something that you should do as a custom RequestHandler -- not a
> SearchComponent or a QParserPlugin.
>
> You can always subclass SearchHandler, and override the handleRequest
> method to manipulate the request however you want and then delegate to
> super.
>
>
> -Hoss
>
Re: custom query string parsing?
Posted by Chris Hostetter <ho...@fucit.org>.
: Essentially, this is what I want to do (I'm extending SearchComponent):
the level of request manipulation you seem to be interested strikes me as
something that you should do as a custom RequestHandler -- not a
SearchComponent or a QParserPlugin.
You can always subclass SearchHandler, and override the handleRequest
method to manipulate the request however you want and then delegate to
super.
-Hoss
Re: custom query string parsing?
Posted by sam ” <sk...@gmail.com>.
Essentially, this is what I want to do (I'm extending SearchComponent):
@Override
public void process(ResponseBuilder rb) throws IOException {
final SolrQueryRequest req = rb.req;
final MultiMapSolrParams requestParams =
SolrRequestParsers.parseQueryString(req.getParamString());
final SolrParams allParams = req.getParams();
final SolrParams defaultParams = allParams - requestParams;
req.setParams(defaultParams + transformToSolrParams(requestParams));
}
where allParams - requestParams will give me default,append,invariant
query params. And, I manually transform requestParams to proper SolrParams,
and sum them up with defaultParams.
On Tue, Apr 10, 2012 at 11:46 AM, sam ” <sk...@gmail.com> wrote:
> I would like to transform the following:
>
> /myhandler/?colors=red&colors=blue&materials=leather
>
> to a Query that is similar to:
> /select/?fq:colors:(red OR
> blue)&fq:materials:leather&facet=on&facet.field=.... and various default
> query params.
>
> I tried to do this by providing QParserPlugin:
> <queryParser name="myQueryParser" class="my.QueryParserPlugin"/>
> <requestHandler name="/myhandler" class="solr.SearchHandler">
> <lst name="defaults">
> <!-- various default params -->
> <str name="defType">myQueryParser</str>
> </lst>
> </requestHandler>
>
>
> In my.QueryParser (returned by my.QueryParserPlugin) I can:
> getReq().getParamString();
>
> and parse that string to get non-default SolrParams.
> And, build a Query object to my liking.
>
> Am I going about the right direction? It'd be much easier if I could
> place a custom app proxying solr... But, I am required to expose solr to
> the public without middle layer between the browsers and solr.
>
> So, my idea is to reject all solr query params but handful of custom
> params such as colors, materials, .. and build a Query object myself
> combining with default SolrParams specified in solrconfig.xml .
>
> Is this feasible? I don't really like to parse query string myself
> (returned by getReq().getParamString()) ..
> getReq().getParams() returns DefaultSolrParams, which does provide a way
> to get non-default params only.
>
>
>
>