[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13768980#comment-13768980
]
Sea Marie edited comment on SOLR-4470 at 9/17/13 12:02 AM:
-----------------------------------------------------------
Hi,
I am running a simple two-node SolrCloud cluster with this patch (pulled from
Jan's GitHub and built from there) using the built-in ZooKeeper and Jetty.
I made a few small changes to the Jetty configs to restrict access via basic
auth on all SOLR resources. After rebooting with these changes, the SolrCore on
my second node is not coming up - it seems like the credentials are not being
used in the core recovery code, or not being passed to ZooKeeper, or something.
Have I missed some configuration step? Or am I confused and this scenario is
not supported by this patch?
h5. Changes I made in Jetty to enable basic auth:
h6. etc/webdefault.xml (perhaps protecting everything is overly general?):
<security-constraint>
<web-resource-collection>
<web-resource-name>Solr authenticated application</web-resource-name>
<url-pattern>/</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>access-role</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>Access Realm</realm-name>
</login-config>
h6. etc/jetty.xml:
<Call name="addBean">
<Arg>
<New class="org.eclipse.jetty.security.HashLoginService">
<Set name="name">Access Realm</Set>
<Set name="config"><SystemProperty name="jetty.home"
default="."/>/etc/realm.properties</Set>
<Set name="refreshInterval">0</Set>
</New>
</Arg>
</Call>
h6. etc/realm.properties (redacted for obvious reasons :))
user: password, access-role
h5. Changes to SOLR-related things:
scripts/ctl.sh (on host2):
SOLR="$JAVABIN -Dbootstrap_confdir=$SOLR_HOME/collection1/conf
-Dcollection.configName=myconf -DzkRun -DzkHost=host1:9983
-Dsolr.solr.home=$SOLR_HOME -Djetty.logs=$INSTALL_PATH/logs/
-Djetty.home=$INSTALL_PATH/ -jar
-DinternalAuthCredentialsBasicAuthUsername=user
-DinternalAuthCredentialsBasicAuthPassword=password $INSTALL_PATH/start.jar
$INSTALL_PATH/etc/jetty.xml"
(on host1, same as above w/o the -DzkHost param)
h5. The error I'm seeing (on "host2", the second node, only. "host1", the
leader is fine):
INFO - 2013-09-16 23:36:58.409;
org.apache.solr.client.solrj.impl.HttpClientUtil; Creating new http client,
config:maxConnections=128&maxConnectionsPerHost=32&followRedirects=false
ERROR - 2013-09-16 23:36:58.433; org.apache.solr.common.SolrException; Error
while trying to recover.
core=collection1:org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:
Server at http://host1:8983/solr returned non ok status:401,
message:Unauthorized
at
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:385)
at
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:180)
at
org.apache.solr.cloud.RecoveryStrategy.sendPrepRecoveryCmd(RecoveryStrategy.java:198)
at
org.apache.solr.cloud.RecoveryStrategy.doRecovery(RecoveryStrategy.java:342)
at org.apache.solr.cloud.RecoveryStrategy.run(RecoveryStrategy.java:219)
was (Author: sapphiremirage):
Hi,
I am running a simple two-node SolrCloud cluster with this patch (pulled from
Jan's GitHub and built from there) using the built-in ZooKeeper and Jetty.
I made a few small changes to the Jetty configs to restrict access via basic
auth on all SOLR resources. After rebooting with these changes, the SolrCore on
my second node is not coming up - it seems like the credentials are not being
used in the core recovery code, or not being passed to ZooKeeper, or something.
Have I missed some configuration step? Or am I confused and this scenario is
not supported by this patch?
Here are the changes I made in Jetty to enable basic auth:
etc/webdefault.xml (perhaps protecting everything is overly general?):
<security-constraint>
<web-resource-collection>
<web-resource-name>Solr authenticated application</web-resource-name>
<url-pattern>/</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>access-role</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>Access Realm</realm-name>
</login-config>
etc/jetty.xml:
<Call name="addBean">
<Arg>
<New class="org.eclipse.jetty.security.HashLoginService">
<Set name="name">Access Realm</Set>
<Set name="config"><SystemProperty name="jetty.home"
default="."/>/etc/realm.properties</Set>
<Set name="refreshInterval">0</Set>
</New>
</Arg>
</Call>
etc/realm.properties (redacted for obvious reasons :))
user: password, access-role
And the changes to SOLR-related things:
scripts/ctl.sh (on host2):
SOLR="$JAVABIN -Dbootstrap_confdir=$SOLR_HOME/collection1/conf
-Dcollection.configName=myconf -DzkRun -DzkHost=host1:9983
-Dsolr.solr.home=$SOLR_HOME -Djetty.logs=$INSTALL_PATH/logs/
-Djetty.home=$INSTALL_PATH/ -jar
-DinternalAuthCredentialsBasicAuthUsername=user
-DinternalAuthCredentialsBasicAuthPassword=password $INSTALL_PATH/start.jar
$INSTALL_PATH/etc/jetty.xml"
(on host1, same as above w/o the -DzkHost param)
And then the error I'm getting (on "host2", the second node, only. "host1", the
leader is fine):
INFO - 2013-09-16 23:36:58.409;
org.apache.solr.client.solrj.impl.HttpClientUtil; Creating new http client,
config:maxConnections=128&maxConnectionsPerHost=32&followRedirects=false
ERROR - 2013-09-16 23:36:58.433; org.apache.solr.common.SolrException; Error
while trying to recover.
core=collection1:org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:
Server at http://host1:8983/solr returned non ok status:401,
message:Unauthorized
at
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:385)
at
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:180)
at
org.apache.solr.cloud.RecoveryStrategy.sendPrepRecoveryCmd(RecoveryStrategy.java:198)
at
org.apache.solr.cloud.RecoveryStrategy.doRecovery(RecoveryStrategy.java:342)
at org.apache.solr.cloud.RecoveryStrategy.run(RecoveryStrategy.java:219)
> Support for basic http auth in internal solr requests
> -----------------------------------------------------
>
> Key: SOLR-4470
> URL: https://issues.apache.org/jira/browse/SOLR-4470
> Project: Solr
> Issue Type: New Feature
> Components: clients - java, multicore, replication (java), SolrCloud
> Affects Versions: 4.0
> Reporter: Per Steffensen
> Assignee: Jan Høydahl
> Labels: authentication, https, solrclient, solrcloud, ssl
> Fix For: 4.5, 5.0
>
> Attachments: SOLR-4470_branch_4x_r1452629.patch,
> SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r1454444.patch,
> SOLR-4470.patch, SOLR-4470.patch
>
>
> We want to protect any HTTP-resource (url). We want to require credentials no
> matter what kind of HTTP-request you make to a Solr-node.
> It can faily easy be acheived as described on
> http://wiki.apache.org/solr/SolrSecurity. This problem is that Solr-nodes
> also make "internal" request to other Solr-nodes, and for it to work
> credentials need to be provided here also.
> Ideally we would like to "forward" credentials from a particular request to
> all the "internal" sub-requests it triggers. E.g. for search and update
> request.
> But there are also "internal" requests
> * that only indirectly/asynchronously triggered from "outside" requests (e.g.
> shard creation/deletion/etc based on calls to the "Collection API")
> * that do not in any way have relation to an "outside" "super"-request (e.g.
> replica synching stuff)
> We would like to aim at a solution where "original" credentials are
> "forwarded" when a request directly/synchronously trigger a subrequest, and
> fallback to a configured "internal credentials" for the
> asynchronous/non-rooted requests.
> In our solution we would aim at only supporting basic http auth, but we would
> like to make a "framework" around it, so that not to much refactoring is
> needed if you later want to make support for other kinds of auth (e.g. digest)
> We will work at a solution but create this JIRA issue early in order to get
> input/comments from the community as early as possible.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
