This has always been the case with Solr. Solr's security model is that clients should not have access to it - only trusted intermediaries should have access to it. Otherwise, it should be locked down at a higher level. That's been the case from day one and still is.
That said, someone did do some work on internode basic auth a while back, but it didn't raise a ton of interest yet. - Mark On Mar 29, 2013, at 2:09 PM, "Vaillancourt, Tim" <tvaillanco...@ea.com> wrote: > Yes, I should have mentioned this is under 4.2 Solr. > > I sort of expected what I'm doing might be unsupported, but basically my > concern is under the current SOLR design, any client with connectivity to > SOLR's port can perform Admin-level API calls like create/drop Cores or > Collections. > > I'm only aiming for '/solr/admin/*' calls to separate "Application" access > from the "Administrative" access logically, and not the non-admin calls like > '/update', although you can cause damage with '/update', too. > > I may try to patch the code to send Basic auth credentials on internal calls > just for fun, but I'm thinking longer-term authentication should be > implemented/added to the SOLR codebase (for at least admin calls) vs playing > with security at the container level, and having the app inside the container > aware of it. > > On the upside, in short testing I was able to get a Collection online using > Cores API only using curl calls w/basic auth. Only the Collections API is > affected due to it calls itself which do not have auth. > > Cheers, > > Tim > > -----Original Message----- > From: Isaac Hebsh [mailto:isaac.he...@gmail.com] > Sent: Friday, March 29, 2013 12:37 AM > To: solr-user@lucene.apache.org > Subject: Re: Basic auth on SolrCloud /admin/* calls > > Hi Tim, > Are you running Solr 4.2? (In 4.0 and 4.1, the Collections API didn't return > any failure message. see SOLR-4043 issue). > > As far as I know, you can't tell Solr to use authentication credentials when > communicating other nodes. It's a bigger issue.. for example, if you want to > protect the "/update" requestHandler, so unauthorized users won't delete your > whole collection, it can interfere the replication process. > > I think it's a necessary mechanism in production environment... I'm curious > how do people use SolrCloud in production w/o it. > > > > > > On Fri, Mar 29, 2013 at 3:42 AM, Vaillancourt, Tim > <tvaillanco...@ea.com>wrote: > >> Hey guys, >> >> I've recently setup basic auth under Jetty 8 for all my Solr 4.x >> '/admin/*' calls, in order to protect my Collections and Cores API. >> >> Although the security constraint is working as expected ('/admin/*' >> calls require Basic Auth or return 401), when I use the Collections >> API to create a collection, I receive a 200 OK to the Collections API >> CREATE call, but the background Cores API calls that are ran on the >> Collection API's behalf fail on the Basic Auth on other nodes with a >> 401 code, as I should have foreseen, but didn't. >> >> Is there a way to tell SolrCloud to use authentication on internal >> Cores API calls that are spawned on Collections API's behalf, or is >> this a new feature request? >> >> To reproduce: >> >> 1. Implement basic auth on '/admin/*' URIs. >> >> 2. Perform a CREATE Collections API call to a node (which will >> return 200 OK). >> >> 3. Notice all Cores API calls fail (Collection isn't created). See >> stack trace below from the node that was issued the CREATE call. >> >> The stack trace I get is: >> >> "org.apache.solr.common.SolrException: Server at http://<HOST >> HERE>:8983/solr<http://%3cHOST%20HERE%3e:8983/solr> returned non ok >> status:401, message:Unauthorized >> at >> org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServe >> r.java:373) >> at >> org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServe >> r.java:181) >> at >> org.apache.solr.handler.component.HttpShardHandler$1.call(HttpShardHan >> dler.java:169) >> at >> org.apache.solr.handler.component.HttpShardHandler$1.call(HttpShardHan >> dler.java:135) at >> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) >> at java.util.concurrent.FutureTask.run(FutureTask.java:138) >> at >> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439 >> ) at >> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) >> at java.util.concurrent.FutureTask.run(FutureTask.java:138) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecu >> tor.java:895) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor. >> java:918) at java.lang.Thread.run(Thread.java:662)" >> >> Cheers! >> >> Tim >> >> >>
