rseitz commented on code in PR #2404:
URL: https://github.com/apache/solr/pull/2404#discussion_r1568077123
##########
solr/core/src/test/org/apache/solr/response/transform/TestSubQueryTransformerDistrib.java:
##########
@@ -61,22 +75,51 @@ public static void setupCluster() throws Exception {
String configName = "solrCloudCollectionConfig";
int nodeCount = 5;
- configureCluster(nodeCount).addConfig(configName, configDir).configure();
+
+ final String SECURITY_JSON =
Review Comment:
I'm seeing identical SECURITY_JSON constants declared in CreateToolTest,
DeleteToolTest, PackageToolTest, PostToolTest,
DistribDocExpirationUpdateProcessorTest, TestPullReplicaWithAuth, and
BasicAuthIntegrationTest. I'd be happy to move all those identical ones to a
common place. Also happy to be told where the common place should be :)
There are some other SECURITY_JSON declarations that differ from the above
ones: CloudAuthStreamingTest, SQLWithAuthzEnabledTest, and
TestAuthorizationTest.
The one I've declared here in TestSuQueryTransformerDistrib is basically the
same as the first group, but I added forwardCredentials=true which tells the
basic auth plugin to propagate creds across internode requests. ~~I thought it
would be _necessary_ for me to add this here, because forwardCredentials=true
was needed in my manual testing. That's to say, in manual testing with
forwardCredentials=false, subqueries did not work -- PKI authentication did not
kick in seamlessly as one might have hoped. So that PKI case is an unresolved
detail re: this fix -- should we _expect_ subqueries to work with basic auth
enabled but forwardCredentials=false and if so, how do we make this work? The
other unresolved detail is that here in TestSuQueryTransformerDistrib, I'm
finding the test passes _regardless_ of whether forwardCredentials is true,
false, or not provided, and I'm not yet sure why this differs from what's
observed in manual testing.~~
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
