Only slaves are public facing and they are read only, with limited query request handlers defined. The above approach is to prevent abusive / in appropriate queries by clients. A query component sounds interesting would this be implemented through an interface so could be separate from solr or would it be sub classing a base component ?
cheers lee c On 9 November 2012 17:24, Amit Nithian <anith...@gmail.com> wrote: > 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 > > > > > > > > > > > > > > >
