Make adding auth info to REST responses more robust #92168
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
If decoding auth information stored with a background task config fails, this will no longer prevent the entire config serialization from working. For example, if an ML datafeed config document somehow contains corrupt authorization headers then it is now possible to list datafeeds.
droberts195
added
>bug
:Security/Authorization
|
Pinging @elastic/es-security (Team:Security) |
|
Hi @droberts195, I've created a changelog YAML for you. |
ywangd
reviewed
Dec 7, 2022
.../plugin/core/src/main/java/org/elasticsearch/xpack/core/security/xcontent/XContentUtils.java
Outdated
Show resolved
Hide resolved
This was referenced Dec 7, 2022
droberts195
added a commit
to droberts195/elasticsearch
that referenced
this pull request
Dec 7, 2022
If decoding auth information stored with a background task config fails, this will no longer prevent the entire config serialization from working. For example, if an ML datafeed config document somehow contains corrupt authorization headers then it is now possible to list datafeeds.
droberts195
added a commit
to droberts195/elasticsearch
that referenced
this pull request
Dec 7, 2022
If decoding auth information stored with a background task config fails, this will no longer prevent the entire config serialization from working. For example, if an ML datafeed config document somehow contains corrupt authorization headers then it is now possible to list datafeeds.
elasticsearchmachine
pushed a commit
that referenced
this pull request
Dec 7, 2022
If decoding auth information stored with a background task config fails, this will no longer prevent the entire config serialization from working. For example, if an ML datafeed config document somehow contains corrupt authorization headers then it is now possible to list datafeeds.
elasticsearchmachine
pushed a commit
that referenced
this pull request
Dec 7, 2022
If decoding auth information stored with a background task config fails, this will no longer prevent the entire config serialization from working. For example, if an ML datafeed config document somehow contains corrupt authorization headers then it is now possible to list datafeeds.
droberts195
added a commit
to droberts195/elasticsearch
that referenced
this pull request
Dec 12, 2022
Due to elastic#41185 datafeeds created prior to 7.0 and not updated since then have unparseable authorization headers in 8.x. In 8.0-8.3 this could easily be a non-issue, as such datafeeds were likely forgotten leftovers and never run. Even if it was a problem, only the datafeed of interest would need updating with any urgency. Due to elastic#87884 datafeeds with authorization headers older than 7.0 prevent _all_ datafeeds being listed in 8.4 and 8.5. This in turn breaks the anomaly detection job management section of the ML UI. The problem is alleviated by elastic#92168 and fixed by elastic#92221, but we should warn users that the problem exists in 8.4.0-8.5.3 inclusive.
jguay
added a commit
to jguay/ElasticMisc
that referenced
this pull request
Dec 12, 2022
Automate running no operation for datafeeds containing unparseable data - elastic/elasticsearch#92168
droberts195
added a commit
that referenced
this pull request
Dec 13, 2022
…2274) Due to #41185 datafeeds created prior to 7.0 and not updated since then have unparseable authorization headers in 8.x. In 8.0-8.3 this could easily be a non-issue, as such datafeeds were likely forgotten leftovers and never run. Even if it was a problem, only the datafeed of interest would need updating with any urgency. Due to #87884 datafeeds with authorization headers older than 7.0 prevent _all_ datafeeds being listed in 8.4 and 8.5. This in turn breaks the anomaly detection job management section of the ML UI. The problem is alleviated by #92168 and fixed by #92221, but we should warn users that the problem exists in 8.4.0-8.5.3 inclusive.
droberts195
added a commit
to droberts195/elasticsearch
that referenced
this pull request
Dec 13, 2022
…astic#92274) Due to elastic#41185 datafeeds created prior to 7.0 and not updated since then have unparseable authorization headers in 8.x. In 8.0-8.3 this could easily be a non-issue, as such datafeeds were likely forgotten leftovers and never run. Even if it was a problem, only the datafeed of interest would need updating with any urgency. Due to elastic#87884 datafeeds with authorization headers older than 7.0 prevent _all_ datafeeds being listed in 8.4 and 8.5. This in turn breaks the anomaly detection job management section of the ML UI. The problem is alleviated by elastic#92168 and fixed by elastic#92221, but we should warn users that the problem exists in 8.4.0-8.5.3 inclusive.
elasticsearchmachine
pushed a commit
that referenced
this pull request
Dec 13, 2022
…2274) (#92318) Due to #41185 datafeeds created prior to 7.0 and not updated since then have unparseable authorization headers in 8.x. In 8.0-8.3 this could easily be a non-issue, as such datafeeds were likely forgotten leftovers and never run. Even if it was a problem, only the datafeed of interest would need updating with any urgency. Due to #87884 datafeeds with authorization headers older than 7.0 prevent _all_ datafeeds being listed in 8.4 and 8.5. This in turn breaks the anomaly detection job management section of the ML UI. The problem is alleviated by #92168 and fixed by #92221, but we should warn users that the problem exists in 8.4.0-8.5.3 inclusive.
droberts195
added a commit
to droberts195/elasticsearch
that referenced
this pull request
Dec 13, 2022
Due to elastic#41185 datafeeds created prior to 7.0 and not updated since then have unparseable authorization headers in 8.x. In 8.0-8.3 this could easily be a non-issue, as such datafeeds were likely forgotten leftovers and never run. Even if it was a problem, only the datafeed of interest would need updating with any urgency. Due to elastic#87884 datafeeds with authorization headers older than 7.0 prevent _all_ datafeeds being listed in 8.4 and 8.5. This in turn breaks the anomaly detection job management section of the ML UI. The problem is alleviated by elastic#92168 and fixed by elastic#92221, but we should warn users that the problem exists in 8.4.0-8.5.3 inclusive. Backport of elastic#92274
droberts195
added a commit
to droberts195/elasticsearch
that referenced
this pull request
Dec 13, 2022
Due to elastic#41185 datafeeds created prior to 7.0 and not updated since then have unparseable authorization headers in 8.x. In 8.0-8.3 this could easily be a non-issue, as such datafeeds were likely forgotten leftovers and never run. Even if it was a problem, only the datafeed of interest would need updating with any urgency. Due to elastic#87884 datafeeds with authorization headers older than 7.0 prevent _all_ datafeeds being listed in 8.4 and 8.5. This in turn breaks the anomaly detection job management section of the ML UI. The problem is alleviated by elastic#92168 and fixed by elastic#92221, but we should warn users that the problem exists in 8.4.0-8.5.3 inclusive. Backport of elastic#92274
elasticsearchmachine
pushed a commit
that referenced
this pull request
Dec 13, 2022
…em (#92323) Due to #41185 datafeeds created prior to 7.0 and not updated since then have unparseable authorization headers in 8.x. In 8.0-8.3 this could easily be a non-issue, as such datafeeds were likely forgotten leftovers and never run. Even if it was a problem, only the datafeed of interest would need updating with any urgency. Due to #87884 datafeeds with authorization headers older than 7.0 prevent _all_ datafeeds being listed in 8.4 and 8.5. This in turn breaks the anomaly detection job management section of the ML UI. The problem is alleviated by #92168 and fixed by #92221, but we should warn users that the problem exists in 8.4.0-8.5.3 inclusive. Backport of #92274
droberts195
added a commit
that referenced
this pull request
Dec 13, 2022
…em (#92324) Due to #41185 datafeeds created prior to 7.0 and not updated since then have unparseable authorization headers in 8.x. In 8.0-8.3 this could easily be a non-issue, as such datafeeds were likely forgotten leftovers and never run. Even if it was a problem, only the datafeed of interest would need updating with any urgency. Due to #87884 datafeeds with authorization headers older than 7.0 prevent _all_ datafeeds being listed in 8.4 and 8.5. This in turn breaks the anomaly detection job management section of the ML UI. The problem is alleviated by #92168 and fixed by #92221, but we should warn users that the problem exists in 8.4.0-8.5.3 inclusive. Backport of #92274
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
If decoding auth information stored with a background task config fails, this will no longer prevent the entire config serialization from working.
For example, if an ML datafeed config document somehow contains corrupt authorization headers then it is now possible to list datafeeds.