I think you can address a lot of these concerns by running some proxy in front of SOLR, such as HAProxy. You should be able to limit only certain URIs (so you can prevent /select queries). HAProxy is a free software load-balancer, and it is very configurable and fairly easy to setup.
On Nov 1, 2011, at 4:54 PM, Alireza Salimi wrote: > sorry, I didn't explain that part. We are the developers of client codes > too. > Meaning that just we know the credentials to access the web container, > and we won't run such queries. > > Right now, I'm writing a subclass of SearchHandler which changes the > SolrParams > to remove 'qt' parameter and limit the 'rows'. It must not be needed, > because > we are assuming that all requests will come from authenticated users, but > just > in case. > > Thanks > > On Tue, Nov 1, 2011 at 4:50 PM, Erik Hatcher <erik.hatc...@gmail.com> wrote: > >> SSL and auth doesn't address that /select can hit any request handler >> defined >> (/select?qt=/update&stream.body=<delete><query>*:*</query></delete>&commit=true). >> Be careful! >> >> But certainly knowing all the issues mentioned on this thread, it is >> possible to lock Solr down and make it safe to hit directly. But not out >> of the box or trivially. >> >> Erik >> >> >> >> On Nov 1, 2011, at 16:09 , Alireza Salimi wrote: >> >>> I'm not sure if anybody has asked these questions before or not. >>> Sorry if they are duplicates. >>> >>> The problem is that the clients (smart phones) of our Solr machines >>> are outside the network in which solr machines are located. So, we >>> need to somehow expose their service to the outside word. >>> >>> What's the safest way to do that? >>> If we implement just a controlled app sitting between those clients >>> we gonna waste lots of processing power because of proxying between >>> Solr and clients. >>> >>> We might also ignore some HTTP headers that Solr would generate >>> such as HTTP Cache headers. Anyways, creating such an application >>> seems to be a lot of work which is not that needed. >>> >>> Erik, do you think even if we use SSL and HTTP Authentication, still >>> it's not a good idea to expose Solr services? >>> >>> >>> >>> On Tue, Nov 1, 2011 at 3:57 PM, Erik Hatcher <erik.hatc...@gmail.com> >> wrote: >>> >>>> Be aware that even /select could have some harmful effects, see >>>> https://issues.apache.org/jira/browse/SOLR-2854 (addressed on trunk). >>>> >>>> Even disregarding that issue, /select is a potential gateway to any >>>> request handler defined via /select?qt=/req_handler >>>> >>>> Again, in general it's not a good idea to expose Solr to anything but a >>>> controlled app server. >>>> >>>> Erik >>>> >>>> On Nov 1, 2011, at 15:51 , Alireza Salimi wrote: >>>> >>>>> What if we just expose '/select' paths - by firewalls and load >> balancers >>>> - >>>>> and >>>>> also use SSL and HTTP basic or digest access control? >>>>> >>>>> On Tue, Nov 1, 2011 at 2:20 PM, Chris Hostetter < >>>> hossman_luc...@fucit.org>wrote: >>>>> >>>>>> >>>>>> : I was wondering if it's a good idea to expose Solr to the outside >>>> world, >>>>>> : so that our clients running on smart phones will be able to use >> Solr. >>>>>> >>>>>> As a general rule of thumb, i would say that it is not a good idea to >>>>>> expose solr directly to the public internet. >>>>>> >>>>>> there are exceptions to this rule -- AOL hosted some live solr >> instances >>>>>> of the Sarah Palin emails for HufPo -- but it is definitely an expert >>>>>> level type thing for people who are so familiar with solr they know >>>>>> exactly what to lock down to make it "safe" >>>>>> >>>>>> for typical users: put an application between your untrusted users and >>>>>> solr and only let that application generate "safe" welformed requests >> to >>>>>> Solr... >>>>>> >>>>>> https://wiki.apache.org/solr/SolrSecurity >>>>>> >>>>>> >>>>>> -Hoss >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Alireza Salimi >>>>> Java EE Developer >>>> >>>> >>> >>> >>> -- >>> Alireza Salimi >>> Java EE Developer >> >> > > > -- > Alireza Salimi > Java EE Developer
