[DOCS] Fixes problematic terminology (#58184)
* [DOCS] Fixes problematic terminology (#58178) * [DOCS] Fixes problematic terminology. * Update docs/reference/snapshot-restore/register-repository.asciidoc Co-authored-by: James Rodewig <james.rodewig@elastic.co>
This commit is contained in:
parent
081da09c72
commit
276a4898ba
|
@ -1,8 +1,8 @@
|
|||
[[painless-api-reference]]
|
||||
== Painless API Reference
|
||||
|
||||
Painless has a strict whitelist for methods and classes per context to
|
||||
ensure all painless scripts are secure. Most of these methods are
|
||||
Painless has a strict list of allowed methods and classes per context to
|
||||
ensure all Painless scripts are secure. Most of these methods are
|
||||
exposed directly from the Java Runtime Environment (JRE) while others
|
||||
are part of Elasticsearch or Painless itself. Below is a list of the available
|
||||
APIs per context. The shared API is available to all contexts, while the
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
== Painless contexts
|
||||
|
||||
A Painless script is evaluated within a context. Each context has values that
|
||||
are available as local variables, a whitelist that controls the available
|
||||
are available as local variables, an allowlist that controls the available
|
||||
classes, and the methods and fields within those classes (API), and
|
||||
if and what type of value is returned.
|
||||
|
||||
|
|
|
@ -14,7 +14,7 @@ provides:
|
|||
* Fast performance: Painless scripts https://benchmarks.elastic.co/index.html#search_qps_scripts[
|
||||
run several times faster] than the alternatives.
|
||||
|
||||
* Safety: Fine-grained whitelist with method call/field granularity. See the
|
||||
* Safety: Fine-grained allowlist with method call/field granularity. See the
|
||||
{painless}/painless-api-reference.html[Painless API Reference] for a
|
||||
complete list of available classes and methods.
|
||||
|
||||
|
|
|
@ -9,9 +9,9 @@ https://en.wikipedia.org/wiki/Multiple_dispatch[runtime types] of the
|
|||
parameters and Java which uses the compile time types of the parameters.
|
||||
|
||||
The consequence of this that Painless doesn't support overloaded methods like
|
||||
Java, leading to some trouble when it whitelists classes from the Java
|
||||
Java, leading to some trouble when it allows classes from the Java
|
||||
standard library. For example, in Java and Groovy, `Matcher` has two methods:
|
||||
`group(int)` and `group(String)`. Painless can't whitelist both of these methods
|
||||
`group(int)` and `group(String)`. Painless can't allow both of these methods
|
||||
because they have the same name and the same number of parameters. So instead it
|
||||
has `group(int)` and `namedGroup(String)`.
|
||||
|
||||
|
|
|
@ -3,4 +3,4 @@
|
|||
|
||||
Scripts are composed of one-to-many <<painless-statements, statements>> and are
|
||||
run in a sandbox that determines what local variables are immediately available
|
||||
along with what APIs are whitelisted for use.
|
||||
along with what APIs are allowed.
|
||||
|
|
|
@ -949,11 +949,10 @@ using basic auth or the password will be sent in plain text.
|
|||
There are a range of <<reindex-ssl,settings>> available to configure the behaviour of the
|
||||
`https` connection.
|
||||
|
||||
Remote hosts have to be explicitly whitelisted in elasticsearch.yml using the
|
||||
Remote hosts have to be explicitly allowed in elasticsearch.yml using the
|
||||
`reindex.remote.whitelist` property. It can be set to a comma delimited list
|
||||
of allowed remote `host` and `port` combinations (e.g.
|
||||
`otherhost:9200, another:9200, 127.0.10.*:9200, localhost:*`). Scheme is
|
||||
ignored by the whitelist -- only host and port are used, for example:
|
||||
of allowed remote `host` and `port` combinations. Scheme is
|
||||
ignored, only the host and port are used. For example:
|
||||
|
||||
|
||||
[source,yaml]
|
||||
|
@ -961,7 +960,7 @@ ignored by the whitelist -- only host and port are used, for example:
|
|||
reindex.remote.whitelist: "otherhost:9200, another:9200, 127.0.10.*:9200, localhost:*"
|
||||
--------------------------------------------------
|
||||
|
||||
The whitelist must be configured on any nodes that will coordinate the reindex.
|
||||
The list of allowed hosts must be configured on any nodes that will coordinate the reindex.
|
||||
|
||||
This feature should work with remote clusters of any version of Elasticsearch
|
||||
you are likely to find. This should allow you to upgrade from any version of
|
||||
|
|
|
@ -15,7 +15,7 @@ provides:
|
|||
* Fast performance: Painless scripts https://benchmarks.elastic.co/index.html#search_qps_scripts[
|
||||
run several times faster] than the alternatives.
|
||||
|
||||
* Safety: Fine-grained whitelist with method call/field granularity. See the
|
||||
* Safety: Fine-grained allowlists with method call/field granularity. See the
|
||||
{painless}/painless-api-reference.html[Painless API Reference] for a
|
||||
complete list of available classes and methods.
|
||||
|
||||
|
|
|
@ -267,10 +267,10 @@ cluster alerts are not displayed.
|
|||
`cluster_alerts.management.blacklist`::
|
||||
|
||||
Prevents the creation of specific cluster alerts. It also removes any applicable
|
||||
watches that already exist in the current cluster. +
|
||||
watches that already exist in the current cluster.
|
||||
+
|
||||
--
|
||||
You can add any of the following watch identifiers to the blacklist:
|
||||
You can add any of the following watch identifiers to the list of blocked alerts:
|
||||
|
||||
* `elasticsearch_cluster_status`
|
||||
* `elasticsearch_version_mismatch`
|
||||
|
|
|
@ -69,7 +69,7 @@ client is used in the HTTP input, the webhook, the slack, pagerduty,
|
|||
and jira actions. This setting can be updated dynamically. It defaults to `*`
|
||||
allowing everything. Note: If you configure this setting and you are using one
|
||||
of the slack/pagerduty actions, you have to ensure that the
|
||||
corresponding endpoints are whitelisted as well.
|
||||
corresponding endpoints are explicitly allowed as well.
|
||||
|
||||
[[ssl-notification-settings]]
|
||||
:ssl-prefix: xpack.http
|
||||
|
|
|
@ -236,7 +236,7 @@ URLs using the `file` protocol must point to the location of a shared filesystem
|
|||
accessible to all master and data nodes in the cluster. This location must be
|
||||
registered in the `path.repo` setting.
|
||||
|
||||
URLs using the `http`, `https`, or `ftp` protocols must be whitelisted in the
|
||||
URLs using the `http`, `https`, or `ftp` protocols must be explicitly allowed with the
|
||||
`repositories.url.allowed_urls` setting. This setting supports wildcards in the
|
||||
place of a host, path, query, or fragment in the URL.
|
||||
====
|
||||
|
|
|
@ -201,7 +201,7 @@ accessible to all master and data nodes in the cluster. This location must be
|
|||
registered in the `path.repo` setting, similar to a
|
||||
<<snapshots-filesystem-repository,shared file system repository>>.
|
||||
|
||||
URLs using the `ftp`, `http`, or `https` protocols must be whitelisted in the
|
||||
URLs using the `ftp`, `http`, or `https` protocols must be explicitly allowed with the
|
||||
`repositories.url.allowed_urls` setting. This setting supports wildcards (`*`)
|
||||
in place of a host, path, query, or fragment in the URL. For example:
|
||||
|
||||
|
|
Loading…
Reference in New Issue