-
Notifications
You must be signed in to change notification settings - Fork 25.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Filter original indices in shard level request #78508
Conversation
This change removes the transient OriginalIndices from the ShardSearchTarget class. It is replaced by an an helper function in the SearchPhaseContext to access the OriginalIndices per cluster alias.
Pinging @elastic/es-search (Team:Search) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you, I like this much better!
server/src/main/java/org/elasticsearch/action/search/AbstractSearchAsyncAction.java
Outdated
Show resolved
Hide resolved
server/src/main/java/org/elasticsearch/action/search/SearchPhaseContext.java
Outdated
Show resolved
Hide resolved
I took another approach and reduced the original indices to the concrete index or aliases that is targeted. We don't need the full list on these per shard request so that should help to speed up authorization too. I updated the PR title and description accordingly, @ywelsch could you take another look ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Implementation looks good. There seem to be test failures though.
server/src/main/java/org/elasticsearch/action/search/TransportSearchAction.java
Outdated
Show resolved
Hide resolved
@@ -99,4 +102,68 @@ public void testResolveWildcardsRegexs() throws Exception { | |||
assertThat((String) getResponse.getSource().get("field3"), equalTo("value3")); | |||
} | |||
|
|||
public void testSearchResolveWildcardsRegexs() throws Exception { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This new test looks good to me, i.e. it can fail without the latest update for a similar scenario as described in previous discussion. Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The change to the TransportSearchAction
LGTM.
Though I believe the alias name will not be included in the ShardSearchRequest
if the alias points to a datastream backing index (the alias points to the index, not to the datastream). Consequently DLS/FLS permissions defined on such aliases will not apply when the search uses these names.
But I'm not even sure we should allow aliases to backing indices of datastreams,
and even then this PR is big enough.
Thanks for the integ test.
I now realize we don't have similar tests for Security with Datastreams....
I added IndicesPermissionsWithAliasesWildcardsAndRegexsTests#testSearchResolveDataStreams just now. I had to change the original indices to include the original index name if the data stream is explicitly requested. It is needed to handle the test case. |
@elasticmachine run elasticsearch-ci/part-2 |
Today the search action send the full list of original indices on every shard request. This change restricts the list to the concrete index of the shard or the alias that was used to resolve it. Relates #78314
Today the search action send the full list of original indices on every shard request.
This change restricts the list to the concrete index of the shard or the alias that was used to resolve it.
Relates #78314