-
Notifications
You must be signed in to change notification settings - Fork 25k
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
Add ability for Watcher's webhook actions to send additional header #93426
Add ability for Watcher's webhook actions to send additional header #93426
Conversation
This commit builds on elastic#92576 by adding the `xpack.notification.webhook.additional_token` and `xpack.notification.webhook.token_hosts` keystore settings to allow an additional token to be sent when Watcher performs a webhook request. This includes both the regular `webhook` action as well as the `email` action that uses an `attachment` parameter to a url (which internally uses a webhook to retrieve the attachment). These settings can both by reloaded by updating the keystore and using the reload secure settings API. `xpack.notification.webhook.additional_token` is the token that will be sent in the header. `xpack.notification.webhook.token_hosts` is a comma-separated list of `host:port` pairs for which the header should be sent. For example, if this contains `localhost:1234,aoeu.com:9182` then the token will only be added to the headers for webhook requests to the `localhost` and `aoeu.com` hosts on the 1234 and 9182 ports respectively.
Hi @dakrone, I've created a changelog YAML for you. |
@elasticmachine update branch |
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.
Draft looks perfectly fine so far
|
||
@Override | ||
public String toString() { | ||
return "WebhookAccount[" + this.hostTokenMap.keySet().stream().map(s -> s + "=********") + "]"; |
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.
😄
@elasticmachine update branch |
I tested this on Cloud with the following watch:
And it works great, so I will toggle this to a regular PR. |
Pinging @elastic/es-data-management (Team:Data Management) |
I pushed another commit that adds the static cluster setting |
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.
Changes look good to me!
…95196) This commit fixes a bug where the internal `WebhookService` was not being used for Watcher's `email` attachment `reporting` or `url` types. This meant that why the additional token configured as part of #93426 was sent for `webhook` Watcher actions, it was not being sent in the HTTP request made when resolving the attachments of the `email` action. To accomplish this, the parts of `WebhookService` that modify and make the request have been extracted, and the `WebhookService` is now used by the `ReportingAttachmentParser` and `HttpEmailAttachmentParser` to perform their HTTP requests. Additionally, some debug logging has been added for when the token is sent (and when a `WebhookService` request is executed).
…lastic#95196) This commit fixes a bug where the internal `WebhookService` was not being used for Watcher's `email` attachment `reporting` or `url` types. This meant that why the additional token configured as part of elastic#93426 was sent for `webhook` Watcher actions, it was not being sent in the HTTP request made when resolving the attachments of the `email` action. To accomplish this, the parts of `WebhookService` that modify and make the request have been extracted, and the `WebhookService` is now used by the `ReportingAttachmentParser` and `HttpEmailAttachmentParser` to perform their HTTP requests. Additionally, some debug logging has been added for when the token is sent (and when a `WebhookService` request is executed).
…95196) (#95256) This commit fixes a bug where the internal `WebhookService` was not being used for Watcher's `email` attachment `reporting` or `url` types. This meant that why the additional token configured as part of #93426 was sent for `webhook` Watcher actions, it was not being sent in the HTTP request made when resolving the attachments of the `email` action. To accomplish this, the parts of `WebhookService` that modify and make the request have been extracted, and the `WebhookService` is now used by the `ReportingAttachmentParser` and `HttpEmailAttachmentParser` to perform their HTTP requests. Additionally, some debug logging has been added for when the token is sent (and when a `WebhookService` request is executed).
This commit builds on #92576 by adding the
xpack.notification.webhook.host_token_pairs
keystore setting to allow an additional token to be sent when Watcher performs a webhook request. This includes both the regularwebhook
action as well as theemail
action that uses anattachment
parameter to a url (which internally uses a webhook to retrieve the attachment).These settings can both by reloaded by updating the keystore and using the reload secure settings API.
xpack.notification.webhook.host_token_pairs
is a comma-separated list of<host>:<port>=<token>
pairs for which the header should be sent. For example, if this containslocalhost:1234=token1,aoeu.com:9182=token2
then the token will only be added to the headers for webhook requests to thelocalhost
andaoeu.com
hosts on the 1234 and 9182 ports with tokenstoken1
andtoken2
respectively.Also added is a cluster setting (non-dynamic) —
xpack.notification.webhook.additional_token_enabled
that determines whether the token should be sent. It defaults tofalse
.