The front-ends can do some quick and dirty scanning before they fire a query. (Most don't do) still possible.
We need a mechanism to filter out queries with some criteria. the /update vulnerability can to be addressed w/ an Apache front ending the server w/ ip based Access control. On Fri, Jul 11, 2008 at 10:38 PM, Erik Hatcher <[EMAIL PROTECTED]> wrote: > > On Jul 11, 2008, at 12:56 PM, Noble Paul നോബിള് नोब्ळ् wrote: >> >> * /update has to be enabled because that is used by the commit script >> to reload any new snapshots > > Even a servlet filter (or fronting web-server*) could turn off /update > requests straightforwardely. Filter to allow only internal servers would do > the trick, no? > > * I'm not necessarily proposing jetty be actually talking directly to > browsers, but no reason why solr.war need be hidden from them either, > providing we iron out whatever /update issues there are. > > Surely there are other alternative ways a Solr instance can be commanded to > pull a new index besides an HTTP request, but I do freely admit that > deployment is not my forte. > >> * user firing queries like *:* can cause heavy load on the server (if >> dismax is the not the only one) > > That's why I specifically constrained to a reasonable query parser. > > The runaway query problem is, though, a problem regardless of whether Solr > is fronted by another web UI tier or not. One could argue that is the > problem of the front-end system to manage, but in reality users are passing > queries straight through without massaging, through any number of layers of > architecture. > > So /update is the only concern with Solr itself being a UI server? > > Erik > > >> >> --Noble >> >> On Fri, Jul 11, 2008 at 10:15 PM, Erik Hatcher >> <[EMAIL PROTECTED]> wrote: >>> >>> On Jul 11, 2008, at 11:08 AM, Noble Paul നോബിള് नोब्ळ् wrote: >>>> >>>> It is not a recommended practice to expose Solr to the end-users >>>> because it is so easy to bring down the server if the user knows that >>>> it is a Solr server. We must devise a good mechanism to filter the >>>> kind of commands that can be served . >>> >>> If all the request handlers were turned off but a /select constrained to >>> dismax, what vulnerabilities exist? >>> >>> Erik >>> >>> >> >> >> >> -- >> --Noble Paul > > -- --Noble Paul
