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
