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 > > >
