Lee, I guess my question was if you are trying to prevent the "big bad world" from doing stuff they aren't supposed to in Solr, how are you going to prevent the big bad world from POSTing a "delete all" query? Or restrict them from hitting the admin console, looking at the schema.xml, solrconfig.xml.
I guess the question here is who is the "big bad world"? The internet at large or employees/colleagues in your organization? If it's the internet at large then I'd totally decouple this from Solr b/c I want to be 100% sure that the *only* thing that the internet has access to is a GET on /select with some restrictions and this could be done in many places but it's not clear that coupling this to Solr is the place to do it. If the "big bad world" is just within your organization and you want some basic protections around what they can and can't see then what you are saying is reasonable to me. Also perhaps another option is to consider a query component rather than creating a sublcass of the request handler as a query component promotes more re-use and flexibility. You could make the necessary parameter changes in the prepare() method and just make sure that this "safe parameter" component comes before the query component in the list of components for a handler and you should be fine. Cheers! Amit On Fri, Nov 9, 2012 at 5:39 AM, Lee Carroll <lee.a.carr...@googlemail.com>wrote: > Hi Amit > > I did not do this via a servlet filter as I wanted the solr devs to be > concerned with solr config and keep them out of any concerns of the > container. By specifying declarative data in a request handler that would > be enough to produce a service uri for an application. > > Or have I missed a point ? We have several cores with several apps all > with different data query needs. Maybe 20 request handlers needed to > support this with active development on going. Basically I want it easy for > devs to create a specific request handler suited to their needs. I thought > a servletfilter developed and mainatined every time would be over kill. > Again though I may have missed a point / over emphasised a difficulty? > > Are you saying my custom request handler is to tightly bound to solr? so > the parameters my apps talk is not de-coupled enough from solr? > > Lee C > > On 7 November 2012 19:49, Amit Nithian <anith...@gmail.com> wrote: > > > Why not do this in a ServletFilter? Alternatively, I'd just write a front > > end application servlet to do this so that you don't firewall your > internal > > admins off from accessing the core Solr admin pages. I guess you could > > solve this using some form of security but I don't know this well enough. > > > > If I were to restrict access to certain parts of Solr, I'd do this > outside > > of Solr itself and do this in a servlet or a filter, inspecting the > > parameters. It's easy to create a "modifiable" parameters class and > > populate that with acceptable parameters before the Solr filter operates > on > > it. > > > > HTH > > Amit > > > > > > > > >
