-
Notifications
You must be signed in to change notification settings - Fork 24.8k
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
Remove Version.V_6_x_x constants use in security #41185
Conversation
This removes some use of the v6 constants in various parts of security. Mostly this is BWC testing code, which is no longer needed as ES8 will not need to maintain compatibility with ES6. Relates: elastic#41164
Pinging @elastic/es-security |
I didn't touch anything to do with Tokens, given the current work being done there. There's also a separate change needed for builtin users that were defined in v6.x, which can be handled separately. |
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.
LGTM
Thought the failures pointed to by elasticsearch-ci/1 in the hlrc project are legit:
Looks like some pruning is required there as well. |
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.
LGTM, Thank you.
…s-in-all-the-places * elastic/master: (70 commits) Remove experimental label froms script_score query (elastic#41572) [Ml-Dataframe] Update URLs in Data frame client java doc (elastic#41539) Reenable bwc Tests in master (elastic#41540) Fix search_as_you_type's sub-fields to pick their names from the full path of the root field (elastic#41541) Remove search analyzers from DocumentFieldMappers (elastic#41484) Update community client and integration docs (elastic#41513) Remove Version.V_6_x_x constants use in security (elastic#41185) Mute testDriverConfigurationWithSSLInURL Remove dedicated SSL network write buffer (elastic#41283) Disable max score optimization for queries with unbounded max scores (elastic#41361) [DOCS] Explicitly set section IDs for Asciidoctor migration (elastic#41547) [ML] add multi node integ tests for data frames (elastic#41508) [Docs] Fix common word repetitions (elastic#39703) [DOCS] Note TESTRESPONSE can't be used immediately after TESTSETUP (elastic#41542) Update configuring-ldap-realm.asciidoc (elastic#40427) Fixed very small typo in date (elastic#41398) Refactor GeoHashUtils (elastic#40869) Make 0 as invalid value for `min_children` in `has_child` query (elastic#41347) field_caps: adapt bwc version after backport (elastic#41427) Remove Exists Check from S3 Repository Deletes (elastic#40931) ...
This removes some use of the v6 constants in various parts of security. Mostly this is BWC testing code, which is no longer needed as ES8 will not need to maintain compatibility with ES6. Relates: elastic#41164
This removes some use of the v6 constants in various parts of security. Mostly this is BWC testing code, which is no longer needed as ES8 will not need to maintain compatibility with ES6. Relates: elastic#41164
Officially Elasticsearch is compatible with last major at data level. Therefore v8 is not compatible with v6. However we don't have a guided migration path for stored authentication headers, e.g. upgrade assistant does not do anything for them. Therefore it is more helpful and user friendly for v8 to support v6 stored authentication headers. This PR adds back the version conditional logic removed in elastic#41185 along with tests.
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.
Officially Elasticsearch is compatible with last major at data level. Therefore v8 is not compatible with v6. However we don't have a guided migration path for stored authentication headers, e.g. upgrade assistant does not do anything for them. Therefore it is more helpful and user friendly for v8 to support v6 stored authentication headers. This PR adds back the version conditional logic removed in #41185 along with tests.
…2221) Officially Elasticsearch is compatible with last major at data level. Therefore v8 is not compatible with v6. However we don't have a guided migration path for stored authentication headers, e.g. upgrade assistant does not do anything for them. Therefore it is more helpful and user friendly for v8 to support v6 stored authentication headers. This PR adds back the version conditional logic removed in elastic#41185 along with tests.
…92295) Officially Elasticsearch is compatible with last major at data level. Therefore v8 is not compatible with v6. However we don't have a guided migration path for stored authentication headers, e.g. upgrade assistant does not do anything for them. Therefore it is more helpful and user friendly for v8 to support v6 stored authentication headers. This PR adds back the version conditional logic removed in #41185 along with tests.
…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.
…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.
…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.
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
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
…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
…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
This removes some use of the v6 constants in various parts of
security.
Mostly this is BWC code, which is no longer needed as ES8 will
not need to maintain compatibility with ES6.
Relates: #41164