Noble Paul commented on SOLR-12161:


update requests done using CloudSolrClient are executed in a threadpool so that 
each shard is requested in a separate thread. Solrj mistakes this to be an 
inter server request and sets the PKI authentication header. So this request is 
considered goes through using PKI authentication. commit() request is performed 
without the same thread (not the thread pool) so it uses basic auth and works 
as expected.


So far so good.


Is it a security vulnerability?


This is executed in the test JVM which already has a valid Solr which in turn 
has a valid PKIAuthenticationPlugin instance. Normally, when SolrJ is used 
outside in a JVM which does not have a Solr running inside, the 
PKIAuthenticationPlugin instance does not exist and the headers cannot be set 
and the request would fail , as expected.


is it a bug?


YES. But limited to the test environment


Is it a regression?


I'm not sure. We need further investigation to know that.

> CloudSolrClient with basic auth enabled will update even if no credentials 
> supplied
> -----------------------------------------------------------------------------------
>                 Key: SOLR-12161
>                 URL: https://issues.apache.org/jira/browse/SOLR-12161
>             Project: Solr
>          Issue Type: Bug
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: Authentication
>    Affects Versions: 7.3
>            Reporter: Erick Erickson
>            Assignee: Noble Paul
>            Priority: Major
>         Attachments: AuthUpdateTest.java, tests.patch
> This is an offshoot of SOLR-9399. When I was writing a test, if I create a 
> cluster with basic authentication set up, I can _still_ add documents to a 
> collection even without credentials being set in the request.
> However, simple queries, commits etc. all fail without credentials set in the 
> request.
> I'll attach a test class that illustrates the problem.
> If I use a new HttpSolrClient instead of a CloudSolrClient, then the update 
> request fails as expected.
> [~noblepaul] do you have any insight here? Possibly something with splitting 
> up the update request to go to each individual shard?

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to