Re: [PR] SOLR-12813: subqueries should respect basic auth [solr]
rseitz commented on PR #2404: URL: https://github.com/apache/solr/pull/2404#issuecomment-2083646456 I opened a separate PR here: https://github.com/apache/solr/pull/2429 Basically, it's a one-line change that updates another `_parser.buildRequestFrom()` call inside `EmbeddedSolrServer.request()`. This other call doesn't seem to be involved in the subquery execution codepath, so it didn't need to be updated for fixing SOLR-12813. In earlier discussion we had here, folks asked if there were other cases we might be missing where a Principal is lost, so I did some more looking around. This is the other such case that I've come across so far. I added some more description on the new PR. -- 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: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-12813: subqueries should respect basic auth [solr]
epugh commented on PR #2404: URL: https://github.com/apache/solr/pull/2404#issuecomment-2082948170 I think open a seperate PR, just to keep the one that was merged and committed seperate from a new one. I'd love to see the suggested PR... Do we also need a test there? -- 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: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-12813: subqueries should respect basic auth [solr]
rseitz commented on PR #2404: URL: https://github.com/apache/solr/pull/2404#issuecomment-2082885569 Thanks @epugh and @dsmiley for the feedback and support for this fix. I'll open a separate ticket for the security.json refactor and tag Eric. There is a minor followup I would like to add here: `EmbeddedSolrServer.request()` has _two_ places where `_parser.buildRequestFrom()` is called. One codepath is when the request handler can be found on the CoreContainer, and the other codepath is when the request handler has to be retrieved from the SolrCore itself. This PR so far only updated the second codepath because that's the path that's active in the subquery execution scenario. To be consistent though, I'm thinking the first codepath should be updated as well. It's a one-line change just to add the Principal to a _parser.buildRequestFrom(). I'm planning to submit to this same branch shortly. Since existing unit tests don't seem to care about this, I'd be interested in any advice on if & how we should add coverage for it. -- 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: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-12813: subqueries should respect basic auth [solr]
epugh commented on PR #2404: URL: https://github.com/apache/solr/pull/2404#issuecomment-2082388354 Thanks @rseitz for the contribution. Tag me on the `security.json` refactor please! -- 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: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-12813: subqueries should respect basic auth [solr]
epugh merged PR #2404: URL: https://github.com/apache/solr/pull/2404 -- 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: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-12813: subqueries should respect basic auth [solr]
rseitz commented on code in PR #2404:
URL: https://github.com/apache/solr/pull/2404#discussion_r158126
##
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:
Quick update -- my comment from last week mentioned some unresolved
questions about what happens when security.json has the setting
`forwardCredentials=false`. I've redone my manual testing and am no longer
seeing a failure in that case, so I'm guessing the earlier problem was a result
of some temporary code changes that never got committed. In manual testing I'm
now seeing subqueries work properly regardless of whether `forwardCredentials`
is true or false, so I'm not thinking of this as an unresolved item anymore.
Regarding the consolidation of SECURITY_JSON across the test suite, I'm
looking for guidance on whether to do it here or whether it could be done in a
separate PR. My preference would be to do it separately so this current PR can
stay small and manageable.
--
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: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-12813: subqueries should respect basic auth [solr]
rseitz commented on code in PR #2404:
URL: https://github.com/apache/solr/pull/2404#discussion_r158126
##
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:
Quick update -- my comment from last week mentioned some unresolved
questions about what happens security.json has the setting
`forwardCredentials=false`. I've redone my manual testing and am no longer
seeing a failure in that case, so I'm guessing the earlier problem was a result
of some temporary code changes that never got committed. In manual testing I'm
now seeing subqueries work properly regardless of whether `forwardCredentials`
is true or false, so I'm not thinking of this as an unresolved item anymore.
Regarding the consolidation of SECURITY_JSON across the test suite, I'm
looking for guidance on whether to do it here or whether it could be done in a
separate PR. My preference would be to do it separately so this current PR can
stay small and manageable.
--
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: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-12813: subqueries should respect basic auth [solr]
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: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-12813: subqueries should respect basic auth [solr]
rseitz commented on code in PR #2404:
URL: https://github.com/apache/solr/pull/2404#discussion_r1580195804
##
solr/core/src/java/org/apache/solr/response/transform/SubQueryAugmenterFactory.java:
##
@@ -340,7 +346,9 @@ public void transform(SolrDocument doc, int docid) {
final SolrParams docWithDeprefixed =
SolrParams.wrapDefaults(new DocRowParams(doc, prefix, separator),
baseSubParams);
try {
- QueryResponse rsp = server.query(coreName, docWithDeprefixed);
+ QueryRequest req = new QueryRequest(docWithDeprefixed);
+ req.setUserPrincipal(principal);
+ QueryResponse rsp = req.process(server, coreName);
Review Comment:
I commented re: SolrRequestInfo separately but will add detail there. The
question is: what can we assume about the contents of SolrRequestInfo? In the
context of subquery execution, what we find at the top of the stack inside
SolrRequestInfo is the _new_ subquery request that we've constructed, not the
enclosing/original request that contained the authentication info. The
following excerpt from EmbeddedSolrServer shows how SolrRequestInfo gets set
before a subquery is actually executed:
```
req = _parser.buildRequestFrom(core, params,
getContentStreams(request));
SolrQueryResponse rsp = new SolrQueryResponse();
SolrRequestInfo.setRequestInfo(new SolrRequestInfo(req, rsp));
core.execute(handler, req, rsp);
```
My basic intuition is that if we're creating a brand new QueryRequest, we
really _should_ be copying any authentication info onto it that needs to be
used in its execution. I don't see any notion in the codebase of a parent/child
relationship between queries, where a child query could somehow know who its
parent is and derive auth info from the parent. Therefore, it really seems to
me like copying the auth info is the logical option.
--
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: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-12813: subqueries should respect basic auth [solr]
rseitz commented on code in PR #2404:
URL: https://github.com/apache/solr/pull/2404#discussion_r1580121540
##
solr/core/src/java/org/apache/solr/servlet/SolrRequestParsers.java:
##
@@ -252,7 +260,11 @@ private SolrQueryRequest buildRequestFrom(
new SolrQueryRequestBase(core, params, requestTimer) {
@Override
public Principal getUserPrincipal() {
-return req == null ? null : req.getUserPrincipal();
+if (principal != null) {
+ return principal;
+} else {
+ return req == null ? null : req.getUserPrincipal();
+}
}
Review Comment:
I tried it and got a stack overflow. Here is what happens:
`EmbeddedSolrServer#request ` uses `SolrRequestParsers#buildRequestFrom` to
obtain a`SolrQueryRequest req`. It then calls
`SolrRequestInfo.setRequestInfo(new SolrRequestInfo(req, rsp))` to designate
that request as the current one (see
[here](https://github.com/apache/solr/blob/9ad70743a218665254f8aff15952ab4859e65b75/solr/core/src/java/org/apache/solr/client/solrj/embedded/EmbeddedSolrServer.java#L224)).
The `getUserPrincipal` method that I'm changing here belongs to an anonymous
inner class that extends `SolrQueryRequestBase`. At the time this
`getUserPrincipal` method is actually called, `SolrRequestInfo.getRequestInfo`
would return a `SolrRequestInfo` containing the same `SolrQueryRequest`
instance that this `getUserPrincipal` method is being called on in the first
place.
Another way to say this is that when we try to call
`SolrRequestInfo#getUserPrincipal` in this scenario, we don't interact with
original or enclosing request that included the original user query and the
auth info. Instead, we interact with the new request that is being created as
part of the subquery execution process.
I haven't noticed a way around this but am certainly eager for suggestions.
--
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: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-12813: subqueries should respect basic auth [solr]
rseitz commented on code in PR #2404:
URL: https://github.com/apache/solr/pull/2404#discussion_r1580121540
##
solr/core/src/java/org/apache/solr/servlet/SolrRequestParsers.java:
##
@@ -252,7 +260,11 @@ private SolrQueryRequest buildRequestFrom(
new SolrQueryRequestBase(core, params, requestTimer) {
@Override
public Principal getUserPrincipal() {
-return req == null ? null : req.getUserPrincipal();
+if (principal != null) {
+ return principal;
+} else {
+ return req == null ? null : req.getUserPrincipal();
+}
}
Review Comment:
I tried it and got a stack overflow. Here is what happens:
`EmbeddedSolrServer#request ` uses `SolrRequestParsers#buildRequestFrom` to
obtain a`SolrQueryRequest req`. It then calls
`SolrRequestInfo.setRequestInfo(new SolrRequestInfo(req, rsp))` to designate
that request as the current one (see
[here](https://github.com/apache/solr/blob/9ad70743a218665254f8aff15952ab4859e65b75/solr/core/src/java/org/apache/solr/client/solrj/embedded/EmbeddedSolrServer.java#L224)).
The `getUserPrincipal` method that I'm changing here belongs to an anonymous
inner class that extends `SolrQueryRequestBase`. At the time this
`getUserPrincipal` method is actually called, `SolrRequestInfo.getRequestInfo`
would return a `SolrRequestInfo` containing the same `SolrQueryRequest`
instance that this `getUserPrincipal` method is being called on in the first
place.
Another way to say this is that when we try to call
`SolrRequestInfo#getUserPrincipal` in this scenario, we don't interact with
original or enclosing request that included the original user query and the
auth info. Instead, we interact with the new request that is being created as
part of the subquery execution process.
--
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: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-12813: subqueries should respect basic auth [solr]
rseitz commented on code in PR #2404:
URL: https://github.com/apache/solr/pull/2404#discussion_r1580121540
##
solr/core/src/java/org/apache/solr/servlet/SolrRequestParsers.java:
##
@@ -252,7 +260,11 @@ private SolrQueryRequest buildRequestFrom(
new SolrQueryRequestBase(core, params, requestTimer) {
@Override
public Principal getUserPrincipal() {
-return req == null ? null : req.getUserPrincipal();
+if (principal != null) {
+ return principal;
+} else {
+ return req == null ? null : req.getUserPrincipal();
+}
}
Review Comment:
I tried it and got a stack overflow. Here is what happens:
`EmbeddedSolrServer#request ` uses `SolrRequestParsers#buildRequestFrom` to
obtain a`SolrQueryRequest req`. It then calls
`SolrRequestInfo.setRequestInfo(new SolrRequestInfo(req, rsp))` to designate
that request as the current one (see
[here](https://github.com/apache/solr/blob/9ad70743a218665254f8aff15952ab4859e65b75/solr/core/src/java/org/apache/solr/client/solrj/embedded/EmbeddedSolrServer.java#L224)).
The `getUserPrincipal` method that I'm changing here belongs to an anonymous
inner class that extends `SolrQueryRequestBase`. At the time this
`getUserPrincipal` method is actually called, `SolrRequestInfo.getRequestInfo`
would return a `SolrRequestInfo` containing the same `SolrQueryRequest`
instance that `getUserPrincipal` is being called on in the first place.
--
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: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-12813: subqueries should respect basic auth [solr]
dsmiley commented on code in PR #2404:
URL: https://github.com/apache/solr/pull/2404#discussion_r1578800441
##
solr/core/src/java/org/apache/solr/response/transform/SubQueryAugmenterFactory.java:
##
@@ -340,7 +346,9 @@ public void transform(SolrDocument doc, int docid) {
final SolrParams docWithDeprefixed =
SolrParams.wrapDefaults(new DocRowParams(doc, prefix, separator),
baseSubParams);
try {
- QueryResponse rsp = server.query(coreName, docWithDeprefixed);
+ QueryRequest req = new QueryRequest(docWithDeprefixed);
+ req.setUserPrincipal(principal);
+ QueryResponse rsp = req.process(server, coreName);
Review Comment:
I'm kind of concerned this is merely one spot of potentially many other
cases. Could/should we depend on SolrRequestInfo to make this automatic?
##
solr/core/src/java/org/apache/solr/servlet/SolrRequestParsers.java:
##
@@ -252,7 +260,11 @@ private SolrQueryRequest buildRequestFrom(
new SolrQueryRequestBase(core, params, requestTimer) {
@Override
public Principal getUserPrincipal() {
-return req == null ? null : req.getUserPrincipal();
+if (principal != null) {
+ return principal;
+} else {
+ return req == null ? null : req.getUserPrincipal();
+}
}
Review Comment:
An idea; not totally sure if it'll work until you try: Instead of passing
in a Principal to buildRequestFrom, I think the line you are changing here
could instead see that *if* HttpServletRequest is null, then see if we can use
`org.apache.solr.request.SolrRequestInfo#getUserPrincipal` which works off a
ThreadLocal internally. There may be no SolrRequestInfo either; so ultimately
may have null.
--
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: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-12813: subqueries should respect basic auth [solr]
rseitz commented on code in PR #2404:
URL: https://github.com/apache/solr/pull/2404#discussion_r1568088624
##
solr/core/src/java/org/apache/solr/client/solrj/embedded/EmbeddedSolrServer.java:
##
@@ -215,8 +215,9 @@ public NamedList request(SolrRequest request,
String coreName)
if (handler == null) {
throw new SolrException(SolrException.ErrorCode.BAD_REQUEST, "unknown
handler: " + path);
}
-
- req = _parser.buildRequestFrom(core, params, getContentStreams(request));
+ req =
+ _parser.buildRequestFrom(
Review Comment:
We could remove the buildRequestFrom() that doesn't take a Principal;
outside of tests, it's used in only two places. Where it's used in
`EmbeddedSolrServer.request(SolrRequest request, String coreName)`, we could
get the Principal from the SolrRequest. Where it's used in
`DirectSolrConnection.request(SolrRequestHandler handler, SolrParams params,
String body)` I think we'd need to pass a null Principal as I'm not seeing
where to get one from in that context.
About the larger question -- are there lots of other cases where enabling
basic auth causes errors -- I don't think I know enough to give a good answer.
I do think that the subquery use case is the most obvious/glaring place for
such an error to arise because it involves creating and executing a brand new
query.
--
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: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-12813: subqueries should respect basic auth [solr]
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: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-12813: subqueries should respect basic auth [solr]
epugh commented on code in PR #2404:
URL: https://github.com/apache/solr/pull/2404#discussion_r1568013748
##
solr/core/src/java/org/apache/solr/client/solrj/embedded/EmbeddedSolrServer.java:
##
@@ -215,8 +215,9 @@ public NamedList request(SolrRequest request,
String coreName)
if (handler == null) {
throw new SolrException(SolrException.ErrorCode.BAD_REQUEST, "unknown
handler: " + path);
}
-
- req = _parser.buildRequestFrom(core, params, getContentStreams(request));
+ req =
+ _parser.buildRequestFrom(
Review Comment:
I wonder, should we have still have a _parser.buildRequestFrom() that
doesn't require the user principal? These days, do we need to make sure that
every method has a user principal? Maybe what I am asking is, are there lots
of other places where, if you enable basic auth, then you get errors because
the oroginal code didn't plan for that?
##
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:
Starting to feel like `SECURITY_JSON` needs to be moved into some sort of
cross cutting concern/utility method as we see this basic code proliferate more
and more ;-). Don't get me wrong, I think it's great we are testing our code
with Basic Auth more!!!
--
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: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
