honeymoose/OpenSearch
1
0
Fork 0
mirror of https://github.com/honeymoose/OpenSearch.git synced 2025-03-25 09:28:27 +00:00
Code Issues Packages Projects Releases Wiki Activity

Docs: Remove remaining references to file and native scripts (#26580)

Browse Source 
relates #25690
This commit is contained in:
Ryan Ernst 2017-09-11 11:39:29 -07:00 committed by GitHub
parent b2e4bfa0a7
commit c0c5d5488f
4 changed files with 5 additions and 22 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
docs/reference/aggregations/metrics/extendedstats-aggregation.asciidoc
View File

@ -109,7 +109,7 @@ GET /exams/_search
// CONSOLE
// TEST[setup:exams]
This will interpret the `script` parameter as an `inline` script with the `painless` script language and no script parameters. To use a file script use the following syntax:
This will interpret the `script` parameter as an `inline` script with the `painless` script language and no script parameters. To use a stored script use the following syntax:
[source,js]
--------------------------------------------------

2
docs/reference/modules/plugins.asciidoc
View File

@ -6,7 +6,7 @@
Plugins are a way to enhance the basic elasticsearch functionality in a
custom manner. They range from adding custom mapping types, custom
analyzers (in a more built in fashion), native scripts, custom discovery
analyzers (in a more built in fashion), custom script engines, custom discovery
and more.
See the {plugins}/index.html[Plugins documentation] for more.

15
docs/reference/modules/scripting/security.asciidoc
View File

@ -47,21 +47,6 @@ Bad:
* Users can write arbitrary scripts, queries, `_search` requests.
* User actions make documents with structure defined by users.
[float]
[[modules-scripting-security-do-no-weaken]]
=== Do not weaken script security settings
By default Elasticsearch will run inline, stored, and filesystem scripts for
the builtin languages, namely the scripting language Painless, the template
language Mustache, and the expression language Expressions. These *ought* to be
safe to expose to trusted users and to your application servers because they
have strong security sandboxes. The Elasticsearch committers do not support any
non-sandboxed scripting languages and using any would be a poor choice because:
1. This drops a layer of security, leaving only Elasticsearch's builtin
<<modules-scripting-other-layers, security layers>>.
2. Non-sandboxed scripts have unchecked access to Elasticsearch's internals and
can cause all kinds of trouble if misused.
[float]
[[modules-scripting-other-layers]]
=== Other security layers

8
docs/reference/modules/scripting/using.asciidoc
View File

@ -178,14 +178,12 @@ DELETE _scripts/calculate-score
=== Script Caching
All scripts are cached by default so that they only need to be recompiled
when updates occur. File scripts keep a static cache and will always reside
in memory. Both inline and stored scripts are stored in a cache that can evict
residing scripts. By default, scripts do not have a time-based expiration, but
when updates occur. By default, scripts do not have a time-based expiration, but
you can change this behavior by using the `script.cache.expire` setting.
You can configure the size of this cache by using the `script.cache.max_size` setting.
By default, the cache size is `100`.
NOTE: The size of stored scripts is limited to 65,535 bytes. This can be
changed by setting `script.max_size_in_bytes` setting to increase that soft
limit, but if scripts are really large then alternatives like
<<modules-scripting-native,native>> scripts should be considered instead.
limit, but if scripts are really large then a
<<modules-scripting-engine,native script engine>> should be considered.