[
https://issues.apache.org/jira/browse/SOLR-13566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16870464#comment-16870464
]
Colvin Cowie commented on SOLR-13566:
-------------------------------------
I've updated the patch to fix the problem. I've used a
MDCAwareSingleThreadExecutor in place of the Thread.
But I was wondering if there should instead be a cached or fixed thread pool
for all DaemonStreams to limit the number of concurrent DaemonStreams? Or are
they limited elsewhere? Or are they intentionally unlimited?
Now that the StreamRunner is no longer a Thread, it can't directly surface the
State of the Thread that will be used for streaming it, which is apparently
needed in the stream's output. So I've instead stashed a reference to the
thread calling run() in a field - which feels a little bit dodgy, but it
appears to work as far as the existing tests go. I'm not sure if there's any
possibility for that to go wrong.
It feels like the "safer" thing would be to use the Future from submit(), or
manually track progress in the StreamRunner?
I guess it comes down to whether "state" is there to track the state of the
Thread itself, or overall the state of the streaming operation? And whether the
enum of Thread.State values is the API for the "state" attribute.
[~erickerickson] I believe you wrote the DaemonStreamApiTest - what do you feel
about this? Thanks
> REINDEXCOLLECTION does not work with (basic) authentication
> -----------------------------------------------------------
>
> Key: SOLR-13566
> URL: https://issues.apache.org/jira/browse/SOLR-13566
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Affects Versions: 8.1.1
> Reporter: Colvin Cowie
> Priority: Major
> Attachments: SOLR-13566.patch, SOLR-13566.patch, responses.txt,
> security.json, solr.log
>
>
> I'm on the Solr 8.1 branch off commit
> f26388d034fe5eadca7416aa63b509b8db2c7688 so I have the authentication fixes
> from SOLR-13510 (intermittent 401s for internode requests)
>
> When trying to use the new REINDEXCOLLECTION command introduced in
> SOLR-11127 with basic auth enabled, the daemon stream fails with repeated
> 401s when trying to access the target collection.
>
> This might be the same problem as SOLR-13472, except it applies even with a
> single node, and this doesn't require role based configuration.
>
> Repro: I added a reindex request in BasicAuthIntegrationTest and it is
> reproducible in there... I don't know what effect it should have on the auth
> metrics, if it were working correctly, so I don't know how to update the test
> properly. But you can add the request towards the end of
> org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth()
>
> _CollectionAdminRequest.ReindexCollection reindexReq =
> CollectionAdminRequest.reindexCollection(COLLECTION);_
> _reindexReq.setBasicAuthCredentials("harry", "HarryIsUberCool");_
> _cluster.getSolrClient().request(reindexReq, COLLECTION);_
>
> Manual Repro:
> run bin/solr -e cloud
> Choose 1 node / 1 shard / 1 replica
> In browser GET
> [http://localhost:8983/solr/admin/collections?action=REINDEXCOLLECTION&name=gettingstarted]
> will succeed
> Enable security: server\scripts\cloud-scripts\zkcli -zkhost localhost:9983
> -cmd putfile /security.json <path to file with this>
>
> {
> "authentication": {
> "blockUnknown": true,
> "class": "solr.BasicAuthPlugin",
> "credentials":
> { "solradmin": "fskh17INKrOTSRCJ8HkamA0L6Uiq1dSMgn4OVy8htME=
> /Q4VgOkwVlP6AMVY+ML+IuodbfV81WEfZ3lFb390bws=" }
> }
> }
>
>
> In browser authenticate (as solradmin : solradmin) and GET
> [http://localhost:8983/solr/admin/collections?action=REINDEXCOLLECTION&name=gettingstarted]
> will time out after 180 seconds
>
> The solr log will show repeated 401s
>
> Setting "forwardCredentials" : true in the security.json does not appear to
> change the outcome.
>
>
> The daemon stream should probably be using PKI auth for the internal request.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
