This change moves the sanitization of the html body of emails to render time instead of at message send time.
Move the sanitization code the the EmailTemplate class.
Add <hr> tag to allowed html tags.
Add global setting `watcher.actions.email.sanitize_html` that defaults to true. If this is set to false html sanitization will be disabled
Add documentation for sanitization disable setting.
Enhance email tests to verify that sanitization is happening at construction time.
Fixeselastic/elasticsearch#356
Original commit: elastic/x-pack-elasticsearch@282a2d85c2
The body of the http input may hold xcontent data (json/yaml). The problem is that today, the body only accepts text and writing
escapted json in text makes it very hard to maintain.
This commit introduces another field settings - `xbody`. Now, use `xbody` for inlined xcontent and `body` for any text content. When `xbody` is used, we keep around the xcontent type and the http request that is then executed will include a content-type header that will match the xcontent type of input.
Original commit: elastic/x-pack-elasticsearch@7210908064
- added dynamic_templates to the index template that make sure not to analyze email addresses and http `path` and `host` under the `watch_execution` object. This will enabled building aggregations over these fields. Also make sure that different time fields in thw `watch_record` are mapped as date types.
- While at it changed the `watch_execution.input_result` mapping such that it's enabled and only disabled `watch_execution.input_result.payload` as different payloads from different sources may conflict with one another in terms of mappings
- Fixed a bug in the `EmailTemplate` building of the `reply_to` field.
- Also, added missing `execution_time` to the `watch_record` (under `watch_execution` object).
Closeselastic/elasticsearch#335
Original commit: elastic/x-pack-elasticsearch@dd28c70bca
The meta data field was known and `metadata` in the docs but the parsing logic expected `meta`.
This change unifies everything to use `metadata`. Also clean up Watch parsing to fail in a more consistent way when unknown fields are encountered.
Fixeselastic/elasticsearch#329
Original commit: elastic/x-pack-elasticsearch@a9013127d8
This change hijacks the document APIs for the .watches index and prevents direct access to these APIs via REST.
This hijacking is controlled by the "watcher.index.rest.direct_access" setting, this setting defaults to false which restricts access to the index. To allow direct access to the .watches index from the REST API set this setting to `true`
Copied json files from core es to test this feature and added comments to the json files indicating why they have been copied from es core.
Fixeselastic/elasticsearch#336
Original commit: elastic/x-pack-elasticsearch@22335750bd
Also added assertions to verify if all watch record not null field are expected to be there at parse time.
Original commit: elastic/x-pack-elasticsearch@42052ae02c
The problem we have today is that since all write operations on a watch are blocked on the watch lock, if a watch is executing for a long time (for whatever reason) the action will simply block and by that hold a `management` thread for potentially a long time. This impacts elasticsearch as a whole - if for example there's an infinite loop in the condition script, then you try to delete/ack/update the watch 5 times (the default size of the management thread pool in elasticsearch is 5). You effectively block all management threads in elasticsearch and from that moment on, the only thing left to do is kill the node.
This commit introduces a timeout for the tree write watch actions - `put`, `ack` and `delete`. It is set to 10 seconds by default, but you can customize it both in java and in the rest API using the standard `master_timeout` query parameter.
Updated the relevant docs.
Fixeselastic/elasticsearch#309
Original commit: elastic/x-pack-elasticsearch@03292db37b
This change disallows the SCAN search type in our search requests used by search input and search transform.
Add tests for this and update the current tests to both detect SCAN and not use SCAN in valid tests.
Original commit: elastic/x-pack-elasticsearch@c9d61930c8
This is a step between the old and elastic/elasticsearch#184 this change unifies the logic that generates the search requests from prototype for SearchTransforms and SearchInputs.
This change also adds the `executed_request` field to the `SearchTransform.Result` that was missing.
Add tests for SearchTransform.Result parsing and all different templating options for SearchTransform along with testing handling of search_type in SearchTransform which was being missed previously.
Fixeselastic/elasticsearch#311
Original commit: elastic/x-pack-elasticsearch@26e68576f5
This input_result may contain different types for the same field names. This will cause mapping failures when we try to write the updated watch record.
This change disables this field and adds a test in the `ManualExecutionTests` to test this case.
Fixeselastic/elasticsearch#307
Original commit: elastic/x-pack-elasticsearch@5340761343
This change will attempt to compile scripts at construction time and throw an exception if a script is bad or missing.
With this change the script is compiled at Executable ctor and then the compiled script is used to get the executable.
Fixeselastic/elasticsearch#262
Original commit: elastic/x-pack-elasticsearch@b49c9debf2
This change changes the watch specific actions put/get/delete/execute/ack to be watcher.<action>_watch.
Original commit: elastic/x-pack-elasticsearch@86a91cb141
ElasticsearchIntegrationTest now has a method called httpClient with a different return type than the watcher AbstractWatcherTests httpclient.
This change renamed the `AbstractWatcherTests.httpClient` to `AbstractWatcherTests.watcherHttpClient`.
Original commit: elastic/x-pack-elasticsearch@d35f076cf2
A watch may contain sensitive data that typically you don't want to expose in plain text. Exposing means:
- storing it as plain text in the `.watches` and `.watch_history` indices
- storing it in memory in plain text (can be access via mem dump)
- returning it to the user via API in plain text
Examples of such sensitive data:
- The `password` for the email service (can be configured on the watch itself)
- The `password` for http input when using basic auth
- The `passowrd` for webhook action when using basic auth
A new `SecretService` (you heard it right... secret service) was added to handel the secrets across the board. When a watch is first added to watcher, this service converts all the sensitive data to secrets. From that moment on, all sensitive data associated with the watch (whether in stored in the index or in memory) is hidden behind the secret. This service is also used to "reveal" the original sensitive data on-demand when needed (for example, when the email is sent, it is sent with the original text).
There are two implementations for the `SecretService`. The default one is "plain text" where the created secrets don't really hide anything. The second implementation is based on Shield. If Shield is installed and enabled, the `ShieldSecretService` is used which uses shield's crypto service to potentially encrypt the sensitive data (only potentially because Shield's system key must be defined for encryption to take effect, without the system key, the crypto service will not encrypt and instead return the sensitive data in plain text)
Note, even when Shield is installed, the encryption of sensitive data will only be applied if the `watcher.shield.encrypt_sensitive_data` setting is set to `true`. By default it is set to `false`.
The `get watch` and `execute watch` APIs were updated to filter out sensitive data (using special "hide secrets" parameter).
When shield is integrated, we use shield's settings filter to filter out sensitive settings from the REST nodes info API (when shield is not installed or enabled, we don't do this filtering).
For this change several other refactoring needed to take place
- The http auth codebase was refactored to be more modular. Just like with other modular constructs in watcher, we separated `HttpAuth` from `ApplicableHttpAuth` where the former is the configuration construct and tha latter is the applicable ("executable") construct.
- Changed `WatchStore#put` to accept a watch (instead of the watch source). That's more natural way of looking at a store. Also, a `Watch` can now create and return itself as `ByteReference`. In addition, we now don't directly store the watch source as it was sent by the user, instead, we first parse it to a watch (important step to both validate the source and convert all sensitive data to secrets) and then serialize the watch back to `ByteReference`. This way we're sure that only the secrets are stored and not the original sensitive data.
- All `ToXContent` implementation were updated to properly propagate the `Params`
Docs were added to the Shield Integration chapter
Original commit: elastic/x-pack-elasticsearch@4490fb0ab8