[
https://issues.apache.org/jira/browse/SOLR-14569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17136195#comment-17136195
]
Isabelle Giguere commented on SOLR-14569:
-----------------------------------------
It took a lot of trial and error, but... I figured it out.
There's a shardHandlerFactory defined in some of the requestHandler in
solrconfig.xml. There's also the global shardHandlerFactory defined in solr.xml
Defining a specific shardHandlerFactory in the /select requestHandler somehow
prevents the SolrAuth from being transferred to shard requests.
Ref: solrconfig.xml in the attached configuration(s)
{code}
<requestHandler name="/select" class="solr.SearchHandler">
<shardHandlerFactory class="HttpShardHandlerFactory">
<int name="socketTimeOut">50000</int>
<int name="connTimeOut">50000</int>
<int name="corePoolSize">5</int>
</shardHandlerFactory>
{code}
If the shardHandlerFactory in the /select requestHandler is removed, the query
on an alias magically works. Authentication info is sent to shards.
What kills me is why...
I went through CHANGES.txt to find hints about why overriding the global
shardHandlerFactory would cause any sort of failures. The only thing I could
find was the mention that since Solr 8.0.0, "HttpShardHandlerFactory's
defaultClient is now a Http2SolrClient". The parameters 'maxConnections',
'maxConnectionsPerHost', which are not supported anymore, and thus could have
been a good reason for a failure, are found neither in solr.xml, nor in
solrconfig.xml.
A quick look at ShardHandlerFactory, HttpShardHandlerFactory, HttpShardHandler,
RequestHandlerBase, SearchHandler does not provide any obvious explanation
either.
Sigh...
> HTTP 401 when searching on alias in secured Solr
> ------------------------------------------------
>
> Key: SOLR-14569
> URL: https://issues.apache.org/jira/browse/SOLR-14569
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Authentication
> Affects Versions: master (9.0), 8.5
> Environment: Unit test on master branch (9x) built on Windows 10 with
> Java 11
> Solr 8.5.0 instance running on CentOS 7.7 with Java 11
> Reporter: Isabelle Giguere
> Priority: Major
> Attachments: SOLR-14569.patch, SOLR-14569.patch,
> curl_requests-responses.txt, security.json, security.json, solr.log,
> solr_conf.zip, updated_solr_conf.zip
>
>
> The issue was first noticed on an instance of Solr 8.5.0, after securing Solr
> with security.json.
> Searching on a single collection returns the expected results, but searching
> on an alias returns HTTP 401.
> *Note that this issue is not reproduced when the collections are created
> using the _default configuration.*
> The attached patch includes a unit test to query on an alias. *Fixed and
> updated as per [~gerlowskija]' comments*
> *Patch applies on master branch (9x)*.
> The unit test is added to the test class that was originally part of the
> patch to fix SOLR-13510.
> I also attach:
> - our product-specific Solr configuration, modified to remove irrelevant
> plugins and fields
> - security.json with user 'admin' (pwd 'admin')
> -- Note that forwardCredentials true or false does not modify the behavior
> To test with this configuration:
> - Download and unzip Solr 8.5.0
> - Modify ./bin/solr.in.sh :
> -- ZK_HOST (optional)
> -- SOLR_AUTH_TYPE="basic"
> -- SOLR_AUTHENTICATION_OPTS="-Dbasicauth=admin:admin"
> - Upload security.json into Zookeeper
> -- ./bin/solr zk cp
> [file:/path/to/security.json|file:///path/to/security.json]
> zk:/path/to/solr/security.json [-z <zk_host>:<zk_port>[/<solr>]]
> - Start Solr in cloud mode
> -- ./bin/solr -c
> - Upload the provided configuration
> - ./bin/solr zk upconfig -z <zk_host>:<zk_port>[/<solr>] -n conf_en -d
> /path/to/folder/conf/
> - Create 2 collections using the uploaded configuration
> -- test1, test2
> - Create an alias grouping the 2 collections
> -- test = test1, test2
> - Query (/select?q=*:*) one collection
> -- results in successful Solr response
> - Query the alias (/select?q=*:*)
> -- results in HTTP 401
> There is no need to add documents to observe the issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
