Re: Basic auth on SolrCloud /admin/* calls
mark -- View this message in context: http://lucene.472066.n3.nabble.com/Basic-auth-on-SolrCloud-admin-calls-tp4052266p4155521.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: Basic auth on SolrCloud /admin/* calls
Did anyone try blocking access to the ports in the firewall level, and allowing all the solr servers in the cluster+given control-machines? Assuming that search request to solr run though a proxy.. -- View this message in context: http://lucene.472066.n3.nabble.com/Basic-auth-on-SolrCloud-admin-calls-tp4052266p4055868.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: Basic auth on SolrCloud /admin/* calls
I've thought about this too, and have heard of some people running a lightweight http proxy upstream of Solr. With the right network restrictions (only way for a client to reach solr is via a proxy + the nodes can still talk to each other), you could achieve the same thing SOLR-4470 is doing, with the drawback of additional proxy and firewall components to maintain, plus added overhead on HTTP calls. A benefit though is a lightweight proxy ahead of Solr could implement HTTP caching, taking some load off of Solr. In a perfect world, I'd say rolling out SOLR-4470 is the best solution, but again, it seems to be losing momentum (please Vote/support the discussion!). While proxies can achieve this, I think enough people have pondered about this to implement this as a feature in Solr. Tim On 14/04/13 12:32 AM, adfel70 wrote: Did anyone try blocking access to the ports in the firewall level, and allowing all the solr servers in the cluster+given control-machines? Assuming that search request to solr run though a proxy.. -- View this message in context: http://lucene.472066.n3.nabble.com/Basic-auth-on-SolrCloud-admin-calls-tp4052266p4055868.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: Basic auth on SolrCloud /admin/* calls
I was looking too for this feature and it seems SOLR-4470 can work but I haven't tried yet. +1 On Sun, Apr 14, 2013 at 12:14 PM, Tim Vaillancourt t...@elementspace.comwrote: I've thought about this too, and have heard of some people running a lightweight http proxy upstream of Solr. With the right network restrictions (only way for a client to reach solr is via a proxy + the nodes can still talk to each other), you could achieve the same thing SOLR-4470 is doing, with the drawback of additional proxy and firewall components to maintain, plus added overhead on HTTP calls. A benefit though is a lightweight proxy ahead of Solr could implement HTTP caching, taking some load off of Solr. In a perfect world, I'd say rolling out SOLR-4470 is the best solution, but again, it seems to be losing momentum (please Vote/support the discussion!). While proxies can achieve this, I think enough people have pondered about this to implement this as a feature in Solr. Tim On 14/04/13 12:32 AM, adfel70 wrote: Did anyone try blocking access to the ports in the firewall level, and allowing all the solr servers in the cluster+given control-machines? Assuming that search request to solr run though a proxy.. -- View this message in context: http://lucene.472066.n3.** nabble.com/Basic-auth-on-**SolrCloud-admin-calls-**tp4052266p4055868.htmlhttp://lucene.472066.n3.nabble.com/Basic-auth-on-SolrCloud-admin-calls-tp4052266p4055868.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: Basic auth on SolrCloud /admin/* calls
This JIRA covers a lot of what you're asking: https://issues.apache.org/jira/browse/SOLR-4470 I am also trying to get this sort of solution in place, but it seems to be dying off a bit. Hopefully we can get some interest on this again, this question comes up every few weeks, it seems. I can confirm the latest patch from this JIRA works as expected, although my primary concern is the credentials appear in the JVM command, and I'd like to move that to a file. Cheers, Tim On 11/04/13 10:41 AM, Michael Della Bitta wrote: It's fairly easy to lock down Solr behind basic auth using just the servlet container it's running in, but the problem becomes letting services that *should* be able to access Solr in. I've rolled with basic auth in some setups, but certain deployments such as Solr Cloud or sharded setups don't play well with auth because there's no good way to configure them to use it. Michael Della Bitta Appinions 18 East 41st Street, 2nd Floor New York, NY 10017-6271 www.appinions.com Where Influence Isn’t a Game On Thu, Apr 11, 2013 at 1:19 PM, Raymond Wikerrwi...@gmail.com wrote: On Apr 11, 2013, at 17:12 , adfel70adfe...@gmail.com wrote: Hi I need to implement security in solr as follows: 1. prevent unauthorized users from accessing to solr admin pages. 2. prevent unauthorized users from performing solr operations - both /admin and /update. Is the conclusion of this thread is that this is not possible at the moment? The obvious solution (to me, at least) would be to (1) restrict access to solr to localhost, and (2) use a reverse proxy (e.g, apache) on the same node to provide authenticated restricted access to solr. I think I've seen recipes for (1), somewhere, and I've used (2) fairly extensively for similar purposes.
RE: Basic auth on SolrCloud /admin/* calls
Hi I need to implement security in solr as follows: 1. prevent unauthorized users from accessing to solr admin pages. 2. prevent unauthorized users from performing solr operations - both /admin and /update. Is the conclusion of this thread is that this is not possible at the moment? -- View this message in context: http://lucene.472066.n3.nabble.com/Basic-auth-on-SolrCloud-admin-calls-tp4052266p4055330.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: Basic auth on SolrCloud /admin/* calls
On Apr 11, 2013, at 17:12 , adfel70 adfe...@gmail.com wrote: Hi I need to implement security in solr as follows: 1. prevent unauthorized users from accessing to solr admin pages. 2. prevent unauthorized users from performing solr operations - both /admin and /update. Is the conclusion of this thread is that this is not possible at the moment? The obvious solution (to me, at least) would be to (1) restrict access to solr to localhost, and (2) use a reverse proxy (e.g, apache) on the same node to provide authenticated restricted access to solr. I think I've seen recipes for (1), somewhere, and I've used (2) fairly extensively for similar purposes.
Re: Basic auth on SolrCloud /admin/* calls
It's fairly easy to lock down Solr behind basic auth using just the servlet container it's running in, but the problem becomes letting services that *should* be able to access Solr in. I've rolled with basic auth in some setups, but certain deployments such as Solr Cloud or sharded setups don't play well with auth because there's no good way to configure them to use it. Michael Della Bitta Appinions 18 East 41st Street, 2nd Floor New York, NY 10017-6271 www.appinions.com Where Influence Isn’t a Game On Thu, Apr 11, 2013 at 1:19 PM, Raymond Wiker rwi...@gmail.com wrote: On Apr 11, 2013, at 17:12 , adfel70 adfe...@gmail.com wrote: Hi I need to implement security in solr as follows: 1. prevent unauthorized users from accessing to solr admin pages. 2. prevent unauthorized users from performing solr operations - both /admin and /update. Is the conclusion of this thread is that this is not possible at the moment? The obvious solution (to me, at least) would be to (1) restrict access to solr to localhost, and (2) use a reverse proxy (e.g, apache) on the same node to provide authenticated restricted access to solr. I think I've seen recipes for (1), somewhere, and I've used (2) fairly extensively for similar purposes.
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.comwrote:
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/solrhttp://%3cHOST%20HERE%3e:8983/solr returned non ok
status:401, message:Unauthorized
at
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:373)
at
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:181)
at
org.apache.solr.handler.component.HttpShardHandler$1.call(HttpShardHandler.java:169)
at
org.apache.solr.handler.component.HttpShardHandler$1.call(HttpShardHandler.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(ThreadPoolExecutor.java:895)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)
Cheers!
Tim
RE: Basic auth on SolrCloud /admin/* calls
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.comwrote:
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/solrhttp://%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
Re: Basic auth on SolrCloud /admin/* calls
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.comwrote:
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/solrhttp://%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
RE: Basic auth on SolrCloud /admin/* calls
Agreed, we don't have clients hitting Solr directly, it is used like a backend
database in our usage by intermediaries, similar to say MySQL. Although
restricting the access to Solr to fewer hosts is something, I still feel an
application has no business being able to perform admin level calls, at least
in my use case. This is being very nitpicky though.
We also open Solr's port to monitoring servers who shouldn't have access to
admin calls and thinking paranoid a compromised app using a single collection
could affect the entire cloud with admin call access.
Seeing the long term plan is to leave this feature at the container level
(which is totally valid), I think I'll continue with the basic auth approach I
attempted and see what I can dig up on past efforts. I'll be sure to share what
I've done.
Thanks Mark!
Tim
-Original Message-
From: Mark Miller [mailto:markrmil...@gmail.com]
Sent: Friday, March 29, 2013 1:04 PM
To: solr-user@lucene.apache.org
Subject: Re: Basic auth on SolrCloud /admin/* calls
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.comwrote:
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/solrhttp://%3cHOST%20HERE%3e:8983/solr returned non ok
status:401, message:Unauthorized
at
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServ
e
r.java:373)
at
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServ
e
r.java:181)
at
org.apache.solr.handler.component.HttpShardHandler$1.call(HttpShardHa
n
dler.java:169)
at
org.apache.solr.handler.component.HttpShardHandler$1.call
RE: Basic auth on SolrCloud /admin/* calls
Here we go:
https://issues.apache.org/jira/browse/SOLR-4470
Tim
-Original Message-
From: Vaillancourt, Tim [mailto:tvaillanco...@ea.com]
Sent: Friday, March 29, 2013 3:25 PM
To: solr-user@lucene.apache.org
Subject: RE: Basic auth on SolrCloud /admin/* calls
Agreed, we don't have clients hitting Solr directly, it is used like a backend
database in our usage by intermediaries, similar to say MySQL. Although
restricting the access to Solr to fewer hosts is something, I still feel an
application has no business being able to perform admin level calls, at least
in my use case. This is being very nitpicky though.
We also open Solr's port to monitoring servers who shouldn't have access to
admin calls and thinking paranoid a compromised app using a single collection
could affect the entire cloud with admin call access.
Seeing the long term plan is to leave this feature at the container level
(which is totally valid), I think I'll continue with the basic auth approach I
attempted and see what I can dig up on past efforts. I'll be sure to share what
I've done.
Thanks Mark!
Tim
-Original Message-
From: Mark Miller [mailto:markrmil...@gmail.com]
Sent: Friday, March 29, 2013 1:04 PM
To: solr-user@lucene.apache.org
Subject: Re: Basic auth on SolrCloud /admin/* calls
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.comwrote:
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/solrhttp://%3cHOST%20HERE%3e:8983/solr returned non ok
status:401, message:Unauthorized
at
org.apache.solr.client.solrj.impl.HttpSolrServer.request
