[
https://issues.apache.org/jira/browse/SOLR-14569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150553#comment-17150553
]
Isabelle Giguere commented on SOLR-14569:
-----------------------------------------
Attached a patch with a fix.
This patch fixes the SearchHandler only, I have not looked at other request
handlers, and it may not be the most elegant fix.
Analysis:
When a shard handler factory is configured directly on a request handler (a
search handler), in solconfig.xml, method SearchHandler.inform(SolrCore)
creates a new instance of ShardHandlerFactory. But in this case, the security
builder of the shard handler factory remains null.
Fix:
Add a boolean marker in ShardHandlerFactory, to indicate if security was
initialized, and method to get the marker.
In SearchHandler.inform(SolrCore), after the new instance of
ShardHandlerFactory is created, verify if security was enabled. In this patch,
call the CoreContainer method getAuthenticationPlugin() and check that it's not
null. We may want to use another marker somewhere, if it can be cleaner.
Also verify if security was enabled in the new shard handler factory, using the
new marker in ShardHandlerFactory.
If security is enabled but the new shard handler factory is not initialized for
it, then set the security builder, by providing the core container's PKI
authentication plugin, following what is done in
CoreContainer.setupHttpClientForAuthPlugin(...)
Adding unit test class TestAuthWithShardHandlerFactoryOverride, and configset.
Note that if you comment-out the lines that set the security builder in
SearchHandler.inform(SolrCore), and try to run these unit tests, they fail with:
{noformat}
org.eclipse.jetty.client.HttpResponseException: HTTP protocol violation:
Authentication challenge without WWW-Authenticate header
{noformat}
So it's not exactly the same error as seen from a query run in Solr Admin UI or
a REST client. But it at least shows there's something wrong with
authentication. I suppose the HTTP protocol violation error is translated into
HTTP 401 in a part of code that the unit test doesn't reach.
Is there some other way to ensure that the search handler's specific shard
handler factory is made aware of security settings ?
> Configuring a shardHandlerFactory on the /select requestHandler results in
> 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, 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.*
> Update: Fast-forward to this comment for the reason why:
> https://issues.apache.org/jira/browse/SOLR-14569?focusedCommentId=17136195&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17136195
> 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.
> Update: Unit tests fail if sharHandlerFactory is added to the requestHandler
> in configset cloud-minimal
> 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 attached configuration solr_conf.zip or updated_solr_conf.zip:
> - 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
