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 ” <skyn...@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_luc...@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 >> > >
