…7458)

While expanding our tests in #126891, we discovered that there was a difference in behaviour when an alias was used during search.

Expected behaviour

When a user uses an alias to access data, we pass this alias also to the node requests because that ensures that the user's authorisation will be evaluated based on the same premise.

Observed behaviour

When a user would use the alias and the ::failures selector, we noticed that the request was resolved to the failure indices and the alias was not used further which sometimes resulted in an unauthorised error. The reason was that when a node different than the coordinating node would try to evaluate if the user has permissions, they would evaluate that against the failure indices themselves and not the alias with the ::failures selector.

Solution
In this PR we ensure that a resolved alias is retrieved for failure indices too.

The indexAliases method is used in two ways (in production code):

To retrieve all the resolved aliases that match an index
To retrieve the filtered aliases that match the index (when there is no unfiltered reference to this index)
Because failure indices are not supported by filtered aliases, the code would return null when a failure index was encountered. That works well for the second case and not for the first.

In order to address that we moved the check for the failure index to the data stream alias predicate and we let the code match failure indices against resolved failure expressions and backing indices against resolved data expressions.

Furthermore, we added methods capturing these two common cases so the users of these methods for not need to know the details of how to call them.

…stic#127458)

While expanding our tests in elastic#126891, we discovered that there was a difference in behaviour when an alias was used during search.

Expected behaviour

When a user uses an alias to access data, we pass this alias also to the node requests because that ensures that the user's authorisation will be evaluated based on the same premise.

Observed behaviour

When a user would use the alias and the ::failures selector, we noticed that the request was resolved to the failure indices and the alias was not used further which sometimes resulted in an unauthorised error. The reason was that when a node different than the coordinating node would try to evaluate if the user has permissions, they would evaluate that against the failure indices themselves and not the alias with the ::failures selector.

Solution
In this PR we ensure that a resolved alias is retrieved for failure indices too.

The indexAliases method is used in two ways (in production code):

To retrieve all the resolved aliases that match an index
To retrieve the filtered aliases that match the index (when there is no unfiltered reference to this index)
Because failure indices are not supported by filtered aliases, the code would return null when a failure index was encountered. That works well for the second case and not for the first.

In order to address that we moved the check for the failure index to the data stream alias predicate and we let the code match failure indices against resolved failure expressions and backing indices against resolved data expressions.

Furthermore, we added methods capturing these two common cases so the users of these methods for not need to know the details of how to call them.

(cherry picked from commit f209db6)

…7458) (#127498)

While expanding our tests in #126891, we discovered that there was a difference in behaviour when an alias was used during search.

Expected behaviour

When a user uses an alias to access data, we pass this alias also to the node requests because that ensures that the user's authorisation will be evaluated based on the same premise.

Observed behaviour

When a user would use the alias and the ::failures selector, we noticed that the request was resolved to the failure indices and the alias was not used further which sometimes resulted in an unauthorised error. The reason was that when a node different than the coordinating node would try to evaluate if the user has permissions, they would evaluate that against the failure indices themselves and not the alias with the ::failures selector.

Solution
In this PR we ensure that a resolved alias is retrieved for failure indices too.

The indexAliases method is used in two ways (in production code):

To retrieve all the resolved aliases that match an index
To retrieve the filtered aliases that match the index (when there is no unfiltered reference to this index)
Because failure indices are not supported by filtered aliases, the code would return null when a failure index was encountered. That works well for the second case and not for the first.

In order to address that we moved the check for the failure index to the data stream alias predicate and we let the code match failure indices against resolved failure expressions and backing indices against resolved data expressions.

Furthermore, we added methods capturing these two common cases so the users of these methods for not need to know the details of how to call them.

(cherry picked from commit f209db6)

This PR adds more test coverage for:

- adding/removing a failure store backing index
- data stream APIs
- watcher

This PR adds more test coverage for:

- adding/removing a failure store backing index
- data stream APIs
- watcher

This PR adds more test coverage for:

- adding/removing a failure store backing index
- data stream APIs
- watcher

This PR adds more test coverage for:

- adding/removing a failure store backing index
- data stream APIs
- watcher